From richard@shockey.us Wed Jun 5 12:23: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 B4C8821F99DD for ; Wed, 5 Jun 2013 12:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.999 X-Spam-Level: X-Spam-Status: No, score=-98.999 tagged_above=-999 required=5 tests=[BAYES_60=1, 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 S1cBxQp8u1g5 for ; Wed, 5 Jun 2013 12:23:34 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id C568221F9A98 for ; Wed, 5 Jun 2013 12:23:32 -0700 (PDT) Received: (qmail 27130 invoked by uid 0); 5 Jun 2013 19:23:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 5 Jun 2013 19:23:08 -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=f7tGPK+vDOpRWdZlqhbyOfgUfZ9PgxQAdXVXKbikC9s=; b=YvdFXu8RLE7mLb+Tqu+NFH/h24EUeaS4NDNMneNlp4I/jH6lXKYE8RNy+geW6GPK7KXAabpVfZcEmsg+qE/EufGrPj3HSTRimttRoprWZv8W3DEHjzu7c4CBqR29OqIh; Received: from [72.66.111.124] (port=50494 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UkJIZ-0007IR-Uc for stir@ietf.org; Wed, 05 Jun 2013 13:23:08 -0600 From: "Richard Shockey" To: Date: Wed, 5 Jun 2013 15:23:03 -0400 Message-ID: <014701ce6222$1ac325d0$50497170$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0148_01CE6200.93B2BE50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac5iIhl3ZJyXiof4Rtq94WH/1hh7gg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: [stir] Testing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 19:23:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0148_01CE6200.93B2BE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0148_01CE6200.93B2BE50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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

 

------=_NextPart_000_0148_01CE6200.93B2BE50-- From hgs@cs.columbia.edu Wed Jun 5 19:34: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 BF60D21F96B1 for ; Wed, 5 Jun 2013 19:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 g089vGbqqM60 for ; Wed, 5 Jun 2013 19:34:15 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3142F21F96A9 for ; Wed, 5 Jun 2013 19:34:10 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r562Y82b025213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 5 Jun 2013 22:34:09 -0400 (EDT) From: Henning Schulzrinne Content-Type: multipart/alternative; boundary="Apple-Mail=_A8E4A4AD-5FBF-4E8A-9535-25D1EA81FC68" Date: Wed, 5 Jun 2013 22:34:07 -0400 References: To: stir@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [stir] FCC report to Congress X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 02:34:20 -0000 --Apple-Mail=_A8E4A4AD-5FBF-4E8A-9535-25D1EA81FC68 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11-1089A1.doc (I was not involved in the drafting of the report.) --Apple-Mail=_A8E4A4AD-5FBF-4E8A-9535-25D1EA81FC68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thread-Topic: STIR vs TERQ Thread-Index: AQHOYo+Ez4A9fHQmpES8lxvoJ/Rvvw== Date: Thu, 6 Jun 2013 08:26:18 +0000 Message-ID: <32456_1370507179_51B047AB_32456_2662_1_B5939C6860701C49AA39C5DA5189448B0A1D6A@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" 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.6.64518 Subject: [stir] STIR vs TERQ X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 08:26:29 -0000 Brian, I was wondering how (whether) this effort would relate with the terq discus= sions given that a) the issues put forward for example in the FCC document = mostly deal with telephone numbers (or name resulting from a number lookup)= and b) that CPN/CLI was I think also part of the terq use cases at some po= int.=20 Reading draft-peterson-secure-origin-ps, I would suspect these discussions = to include (but not necessarily be limited to) telephone numbers and theref= ore stir be related to (but distinct from) terq. The former might be intere= sted in the horizontal interface and the latter with the DB/data model in t= he same way as, say, RFC 4474 could have been related to an enum DB. (Or ma= ybe the latter's been shelved for a time until this one progresses...?)=20 One way or another I would have an interest in this but clarification would= be appreciated. Thanks.=20 Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Rosen, Brian Sent: Wednesday, June 05, 2013 9:25 PM To: DISPATCH list Subject: [dispatch] New effort on source identity in SIP to reduce robocall= ing, swatting and vishing We have started a new effort to reduce robocalling, swatting and vishing in= a SIP network following the ideas presented by Henning Schulzrinne in his = presentation at IETF 86 Orlando and the recent SIPNOC. =A0Fundamentally, we= plan to minimize the ability to spoof the caller's id. =A0 We have created= a new ietf list, stir@ietf.org, where stir stands for "Secure Telephone Id= entity Revisited". =A0 =A0=20 Our emphasis in this effort is deployable solutions that can significantly = reduce problems in a year or two, not solutions that take a revolution in h= ow service provider and enterprises deploy SIP networks. =A0For that reason= , we are particularly interested in getting active participation by as many= SIP service providers as possible, as well as the vendors that serve them. Some discussion has been ongoing among a group of us, and a meeting was hel= d last week to see if we had enough common vision to initiate an IETF effor= t we thought would actually get deployed. =A0So if you get on the list, you= will see discussion on specific points already underway.=A0 If you are interested in working on this effort, or want to stay informed, = you can subscribe by visiting: https://www.ietf.org/mailman/listinfo/stir We hope to arrange a session in Berlin, details will be forthcoming. Brian ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From br@brianrosen.net Thu Jun 6 06:15: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 80CA221F99DA for ; Thu, 6 Jun 2013 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 OVcYcHxH5WVo for ; Thu, 6 Jun 2013 06:15:03 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1455C21F99D8 for ; Thu, 6 Jun 2013 06:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=42wJ8KJF08sn92/wEPGLxlvjKes/Vha139jgV1jCUNo=; b=kfaMjn7cQQ2BwR6PNl63gTgdrTHKxCzQD8uB1pAt3fr4Pvzasixnry+6arhJZEEi9VdPZxQ2FPHiynl386Gwh2qucO0bkKTla/vmZvt/RGy6jE7Pb9aURejWKbBTpn6IRBwg1qRLUubkTqNpSf83iFTmiUpzDSy1krj/pxAjOYo=; Received: from neustargw.va.neustar.com ([209.173.53.233]:30640 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uka1t-0006z4-63; Thu, 06 Jun 2013 09:15:02 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <32456_1370507179_51B047AB_32456_2662_1_B5939C6860701C49AA39C5DA5189448B0A1D6A@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 6 Jun 2013 09:14:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94088B9F-E739-4AF2-8A41-6154C30144BE@brianrosen.net> References: <32456_1370507179_51B047AB_32456_2662_1_B5939C6860701C49AA39C5DA5189448B0A1D6A@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" Subject: Re: [stir] STIR vs TERQ X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 13:15:11 -0000 stir is indeed mostly concerned with telephone numbers as the source = identity. Of course there could be relationships between TERQ and stir, since TERQ = is intended to encompass a database that has lots of information related = to a telephone number. =20 One difference is that stir is organized around immediately deployable = solutions, where TERQ does not have that emphasis. We would not want to = predicate some important feature of stir on some deployment of TERQ. It would seem that the solutions we believe will arise will involve = cryptographic signatures over header elements in the call signaling, = like 4474, although there are proponents of additional capabilities that = would involve databases or services that are used when in-band signaling = does not maintain the headers needed to determine if the source id is = valid. The credentials for signing need to be available. TERQ is one = place to put them. The out-of-band database may not be monolithic and = the one serving a particular calling or called party might be located = via a TERQ database. However, as above, we would want solutions for = these items that are deployable now, and not only when we get TERQ = deployment. Brian On Jun 6, 2013, at 4:26 AM, philippe.fouquart@orange.com wrote: > Brian, >=20 > I was wondering how (whether) this effort would relate with the terq = discussions given that a) the issues put forward for example in the FCC = document mostly deal with telephone numbers (or name resulting from a = number lookup) and b) that CPN/CLI was I think also part of the terq use = cases at some point.=20 >=20 > Reading draft-peterson-secure-origin-ps, I would suspect these = discussions to include (but not necessarily be limited to) telephone = numbers and therefore stir be related to (but distinct from) terq. The = former might be interested in the horizontal interface and the latter = with the DB/data model in the same way as, say, RFC 4474 could have been = related to an enum DB. (Or maybe the latter's been shelved for a time = until this one progresses...?)=20 >=20 > One way or another I would have an interest in this but clarification = would be appreciated. > Thanks.=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Rosen, Brian > Sent: Wednesday, June 05, 2013 9:25 PM > To: DISPATCH list > Subject: [dispatch] New effort on source identity in SIP to reduce = robocalling, swatting and vishing >=20 > We have started a new effort to reduce robocalling, swatting and = vishing in a SIP network following the ideas presented by Henning = Schulzrinne in his presentation at IETF 86 Orlando and the recent = SIPNOC. Fundamentally, we plan to minimize the ability to spoof the = caller's id. We have created a new ietf list, stir@ietf.org, where = stir stands for "Secure Telephone Identity Revisited". =20 >=20 > Our emphasis in this effort is deployable solutions that can = significantly reduce problems in a year or two, not solutions that take = a revolution in how service provider and enterprises deploy SIP = networks. For that reason, we are particularly interested in getting = active participation by as many SIP service providers as possible, as = well as the vendors that serve them. >=20 > Some discussion has been ongoing among a group of us, and a meeting = was held last week to see if we had enough common vision to initiate an = IETF effort we thought would actually get deployed. So if you get on = the list, you will see discussion on specific points already underway.=20= >=20 > If you are interested in working on this effort, or want to stay = informed, you can subscribe by visiting: > https://www.ietf.org/mailman/listinfo/stir >=20 > We hope to arrange a session in Berlin, details will be forthcoming. >=20 > Brian >=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, > France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Thu Jun 6 14:05: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 3EDB421F99D2 for ; Thu, 6 Jun 2013 14:05:14 -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 k34Mg6C24Ftw for ; Thu, 6 Jun 2013 14:05:07 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id B1EF711E811B for ; Thu, 6 Jun 2013 14:05:00 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c79f0b15.0.451291.00-338.1252361.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 06 Jun 2013 21:05:00 +0000 (UTC) X-MXL-Hash: 51b0f97c5004bef1-3c1b9f00db6554ca178f3fc3425f8bcd7f1ef58c 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 r56L4xDl020985 for ; Thu, 6 Jun 2013 17:04:59 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r56L4peu020847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jun 2013 17:04:56 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Thu, 6 Jun 2013 21:04:37 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 17:04:40 -0400 From: "DOLLY, MARTIN C" To: "stir@ietf.org" Thread-Topic: Re: A 4474 that will work through SBCs (generally/potentially Thread-Index: Ac5i+XNhJSk7jFNtS4eNiIdS3GjNjQ== Date: Thu, 6 Jun 2013 21:04:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.82.199] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560215BD8CMISOUT7MSGUSR9I_" 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=f6r/8pOM c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=54kC7f4x02sA:10 a=MLMn8oZ96CUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=eA7Mj05e3] X-AnalysisOut: [BMA:10 a=yXOkaXPSAAAA:8 a=jU2thFBwAAAA:8 a=sRxaGOVFgpHWITx] X-AnalysisOut: [S_a4A:9 a=wPNLvfGTeEIA:10 a=1AMfzNb-s8QA:10 a=qM39cor4HRgA] X-AnalysisOut: [:10 a=yDfFGXr2RxwA:10 a=0SpQNr0Kj84A:10 a=Hz7IrDYlS0cA:10 ] X-AnalysisOut: [a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=LABYw9ucZ39OPNVh:21] Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 21:05:14 -0000 --_000_E42CCDDA6722744CB241677169E836560215BD8CMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. But the interface to the user needs to be easily understood to the= user, independent of device. -----Original Message----- From: source-auth@cdt.org [mailto:source-auth@cdt.org] On Behalf Of Jean-Fr= ancois Mule Sent: Wednesday, June 05, 2013 1:18 PM To: source-auth@cdt.org Subject: Re: A 4474 that will work through SBCs (generally/potentially) There may exist options for presenting unsigned calls to end-users and allow them to decide on a call rejection. I would encourage the separation of end-users from service providers and hope the technical solution can enable multiple policies for SSPs and regulators to choose from (SIP Service Providers could be enterprises, SMS, service operators, or my asterisk software). Jean-Francois. --- Jean-Fran=E7ois Mul=E9 Mobile:+1-415-881-7178 mailto:jfm@cablelabs.com Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_E42CCDDA6722744CB241677169E836560215BD8CMISOUT7MSGUSR9I_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree. But the interface to the user needs to be easily understood t= o the user, independent of device.
 
-----Original Message-----
Sent: Wednesday, June 05, 2013 1:18 PM
To: source-auth@cdt.org
Subject: Re: A 4474 that will work through SBCs (generally/potentially= )
 
There may exist options for presenting unsigned calls to end-users and=
allow them to decide on a call rejection.
 
I would encourage the separation of end-users from service providers a= nd
hope the technical solution can enable multiple policies for SSPs and<= /div>
regulators to choose from (SIP Service Providers could be enterprises,=
SMS, service operators, or my asterisk software).
 
Jean-Francois.
---
Jean-Fran=E7ois Mul=E9
Mobile:+1-415-881-7178
mailto:jfm@cablelabs.com
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T La= bs
md3135@att.com
+1-609-903-3360
 
 
 
 --_000_E42CCDDA6722744CB241677169E836560215BD8CMISOUT7MSGUSR9I_-- From richard@shockey.us Thu Jun 6 15:16: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 B242611E80F8 for ; Thu, 6 Jun 2013 15:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[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 LcizjCxXT2Lq for ; Thu, 6 Jun 2013 15:16:09 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id D2ACC21E8056 for ; Thu, 6 Jun 2013 15:16:08 -0700 (PDT) Received: (qmail 4354 invoked by uid 0); 6 Jun 2013 22:15:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 6 Jun 2013 22:15:44 -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=2QuBSNphykaj0fCAp5LfIfROJsoQzraD8x5//ox7TlI=; b=G/PH4mz2RaklbTHCgTG2dZxnl3tfH/ps9OqNRzdt0OzJVqj8XZfhM311SGH4pSHMAwHDPCkvF9gyRJSQLNMpdd0lVc3K5zMOiUp5f95pzU4lLj6ZrzVNv84AsQAY0+T0; Received: from [72.66.111.124] (port=60842 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UkiT9-000092-HW; Thu, 06 Jun 2013 16:15:44 -0600 From: "Richard Shockey" To: "'DOLLY, MARTIN C'" , References: In-Reply-To: Date: Thu, 6 Jun 2013 18:15:40 -0400 Message-ID: <005401ce6303$61afdc90$250f95b0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CE62E1.DAA2F780" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLL2/5hZfG36NTKy5kQoCO9n9Es3ZcuS6RA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 22:16:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CE62E1.DAA2F780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let=92s be realistic. For the consumer that is being grossly affected = by this problem you are dealing with a class of consumer device that is, for the time being, is not going to display any type of reputation information beyond =93unknown=94 even in the enterprise this is not going to work = too well. =20 I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m happy = to do that. I expect that they can simply manage the service in an appropriate manner to keep me paying them X per month. We have seen the failure of = DKIM we do not want the Public SIP Telephony Network to end up like .. =20 This is going to end up being a service provider problem first then something else as the SIP/IMS networks evolve.=20 =20 My life and ours is complicated enough.=20 =20 Simple wins.=20 =20 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Thursday, June 06, 2013 5:05 PM To: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially =20 I agree. But the interface to the user needs to be easily understood to = the user, independent of device. =20 -----Original Message----- From: source-auth@cdt.org [ mailto:source-auth@cdt.org] On Behalf Of Jean-Francois Mule Sent: Wednesday, June 05, 2013 1:18 PM To: source-auth@cdt.org Subject: Re: A 4474 that will work through SBCs (generally/potentially) =20 There may exist options for presenting unsigned calls to end-users and allow them to decide on a call rejection. =20 I would encourage the separation of end-users from service providers and hope the technical solution can enable multiple policies for SSPs and regulators to choose from (SIP Service Providers could be enterprises, SMS, service operators, or my asterisk software). =20 Jean-Francois. --- Jean-Fran=E7ois Mul=E9 Mobile:+1-415-881-7178 mailto:jfm@cablelabs.com =20 Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 =20 =20 =20 ------=_NextPart_000_0055_01CE62E1.DAA2F780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Let’s be = realistic.=A0 For the consumer = that is being grossly affected by this problem you are dealing with a = class of consumer device that is, for the time being, is not going to = display any type of reputation information beyond =A0“unknown” even in the = enterprise this is not going to work too well.

 

I pay = Verizon or ATT or Bell Canada or Orange for a service. I’m happy = to do that. I expect that they can simply manage the service in an = appropriate manner to keep me paying them X per month. =A0We have seen the failure of DKIM we = do not want the Public SIP Telephony Network to end up like = ..

 

This = is going to end up being a service provider problem first then something = else as the SIP/IMS networks evolve.

 

My = life and ours is complicated enough.

 

Simple = wins.

 

From: stir-bounces@ietf.org = [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C
Sent: Thursday, June 06, 2013 5:05 PM
To: = stir@ietf.org
Subject: Re: [stir] A 4474 that will work = through SBCs = (generally/potentially

 

I agree. But the interface to the user = needs to be easily understood to the user, independent of = device.

 

-----Original = Message-----

From: source-auth@cdt.org [mailto:source-auth@cdt.org] On Behalf Of Jean-Francois = Mule

Sent: Wednesday, June 05, 2013 1:18 = PM

Subject: Re: A 4474 that will work = through SBCs = (generally/potentially)

 

There may exist options for presenting = unsigned calls to end-users = and

allow them to decide on a call = rejection.

 

I would encourage the separation of = end-users from service providers = and

hope the technical solution can enable = multiple policies for SSPs and

regulators to choose from (SIP Service = Providers could be = enterprises,

SMS, service operators, or my asterisk = software).

 

Jean-Francois.

---

Jean-Fran=E7ois = Mul=E9

Mobile:+1-415-881-7178

 

Martin Dolly
Lead Member Technical = Staff

Core & Government/Regulatory = Standards
AT&T Labs
md3135@att.com

+1-609-903-3360

 

 

 

------=_NextPart_000_0055_01CE62E1.DAA2F780-- From md3135@att.com Thu Jun 6 15:27: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 2AE1721F9990 for ; Thu, 6 Jun 2013 15:27:42 -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 ggE-2brCdeXS for ; Thu, 6 Jun 2013 15:27:35 -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 CFFF321F9998 for ; Thu, 6 Jun 2013 15:27:34 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6dc01b15.0.517551.00-490.1426687.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 06 Jun 2013 22:27:34 +0000 (UTC) X-MXL-Hash: 51b10cd62e926c90-2fb95ac560617d29410318d272b0017f6bf7f3a2 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 r56MRXka006460; Thu, 6 Jun 2013 18:27:34 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r56MRRtP006187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 18:27:28 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 6 Jun 2013 22:27:14 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 18:27:18 -0400 From: "DOLLY, MARTIN C" To: Richard Shockey Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOYwNq0ALSXDZCyEmtgvtHhkZiE5kpQ/kN Date: Thu, 6 Jun 2013 22:27:17 +0000 Message-ID: <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> In-Reply-To: <005401ce6303$61afdc90$250f95b0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3318BDF13F8B4867AEEE16183949B000attcom_" 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=EcF/toaC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=oOBisLQmZ4cA:10 a=48vgC7mUAAAA:8 a=yXOkaXPSA] X-AnalysisOut: [AAA:8 a=jU2thFBwAAAA:8 a=EfY9LuH_CiBtxZwDYjQA:9 a=pILNOxqG] X-AnalysisOut: [KmIA:10 a=1AMfzNb-s8QA:10 a=qM39cor4HRgA:10 a=vRAbILRZcFsA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=yDfFGXr2RxwA:10 a=0SpQNr0Kj84A:10 ] X-AnalysisOut: [a=Hz7IrDYlS0cA:10 a=5Bu1EjNNqDBmg3oJ:21 a=RU8Um-7-6Du_a2g_] X-AnalysisOut: [:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 ] X-AnalysisOut: [a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=J_gWf4oqx0hmuPTl:21 ] X-AnalysisOut: [a=eQtO8bB5sHPK3FqS:21 a=iF65haIqdcA2ff2C:21] Cc: "stir@ietf.org" Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 22:27:42 -0000 --_000_3318BDF13F8B4867AEEE16183949B000attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that only a simple solution that addresses IP space is the Big Bang= for the buck We might add an extension for authentication assurance Martin Dolly AT&T Sent from my iPhone On Jun 6, 2013, at 6:15 PM, "Richard Shockey" > wrote: Let=92s be realistic. For the consumer that is being grossly affected by t= his problem you are dealing with a class of consumer device that is, for th= e time being, is not going to display any type of reputation information be= yond =93unknown=94 even in the enterprise this is not going to work too we= ll. I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m happy to= do that. I expect that they can simply manage the service in an appropriat= e manner to keep me paying them X per month. We have seen the failure of D= KIM we do not want the Public SIP Telephony Network to end up like .. This is going to end up being a service provider problem first then somethi= ng else as the SIP/IMS networks evolve. My life and ours is complicated enough. Simple wins. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Thursday, June 06, 2013 5:05 PM To: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly I agree. But the interface to the user needs to be easily understood to the= user, independent of device. -----Original Message----- From: source-auth@cdt.org [mailto:source-auth@c= dt.org] On Behalf Of Jean-Francois Mule Sent: Wednesday, June 05, 2013 1:18 PM To: source-auth@cdt.org Subject: Re: A 4474 that will work through SBCs (generally/potentially) There may exist options for presenting unsigned calls to end-users and allow them to decide on a call rejection. I would encourage the separation of end-users from service providers and hope the technical solution can enable multiple policies for SSPs and regulators to choose from (SIP Service Providers could be enterprises, SMS, service operators, or my asterisk software). Jean-Francois. --- Jean-Fran=E7ois Mul=E9 Mobile:+1-415-881-7178 mailto:jfm@cablelabs.com Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 --_000_3318BDF13F8B4867AEEE16183949B000attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I agree that only a simple solution that addresses IP space is the Big= Bang for the buck

We might add an extension for authentication assurance  &nbs= p;

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 6, 2013, at 6:15 PM, "Richard Shockey" <richard@shockey.us> wrote:

Let=92s be realistic.  For the consumer that is being grossly affected by this problem you = are dealing with a class of consumer device that is, for the time being, is= not going to display any type of reputation information beyond  =93unknown=94 even in the ent= erprise this is not going to work too well.

 

I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m happy to do that. I expect t= hat they can simply manage the service in an appropriate manner to keep me = paying them X per month.  We have seen the failure of D= KIM we do not want the Public SIP Telephony Network to end up like ..<= /o:p>

 

This is going to end up being a service provider problem first then something else as the SIP/I= MS networks evolve.

 

My life and ours is complicated enough.

 

Simple wins.

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Thursday, June 06, 2013 5:05 PM
To: stir@ietf.org
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially

&nbs= p;

I agree. But the in= terface to the user needs to be easily understood to the user, independent of device.

 

-----Original Messa= ge-----

From: source-auth@cdt.org [mailto:source-auth@cdt.org= ] On Behalf Of Jean-Francois Mule

Sent: Wednesday, Ju= ne 05, 2013 1:18 PM

To: source-auth@cdt.org<= /span>

Subject: Re: A 4474= that will work through SBCs (generally/potentially)

 

There may exist opt= ions for presenting unsigned calls to end-users and

allow them to decid= e on a call rejection.

 

I would encourage t= he separation of end-users from service providers and

hope the technical = solution can enable multiple policies for SSPs and=

regulators to choos= e from (SIP Service Providers could be enterprises,

SMS, service operat= ors, or my asterisk software).

 

Jean-Francois.=

---

Jean-Fran=E7ois Mul= =E9

Mobile:+1-415-8= 81-7178

mailto:= jfm@cablelabs.com<= /span>

 

Martin Dolly
Lead Member Technical Staff

Core & Governme= nt/Regulatory Standards
AT&T Labs
md3135@att.com

+1-609-903-3360=

 

 

 

--_000_3318BDF13F8B4867AEEE16183949B000attcom_-- From br@brianrosen.net Thu Jun 6 15:31: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 B859921F99A9 for ; Thu, 6 Jun 2013 15:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 LzVccpzcKljn for ; Thu, 6 Jun 2013 15:31:13 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id C331021F99A1 for ; Thu, 6 Jun 2013 15:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zRPxLXR0ub3HwjJkw+4x5RN46sMwbZCLdw4g7kkLhQo=; b=jlm2hS4UYygPaVGRgV8fMVznLpVdl3k/qRSA7q3XSZyHvnMJimvR7OTD7k+S8oFhYHuRBhWfjDKTMsmxgYukFyRXugyVDl8XgJh9/6k6CJJ0aclNWUXKv93ZIyfaFLQVySO9ldkEPHGPyL7GwYmgUuSH/DAL9Mmlbm3JVKpgy/A=; Received: from neustargw.va.neustar.com ([209.173.53.233]:38914 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ukii6-0003xW-Ao; Thu, 06 Jun 2013 18:31:11 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_ED32AEEC-6C4F-4172-84C6-FA7EDA1D74F5" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> Date: Thu, 6 Jun 2013 18:31:08 -0400 Message-Id: <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 22:31:17 -0000 --Apple-Mail=_ED32AEEC-6C4F-4172-84C6-FA7EDA1D74F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Since virtually no bad calls are SIP end to end, it would seem that we = need something that lets us go SIP to PSTN to SIP, early on. I do think there are opportunities to show more info, but I get the = point about paying the service provider for a reliable service. Brian On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" wrote: > I agree that only a simple solution that addresses IP space is the Big = Bang for the buck >=20 > We might add an extension for authentication assurance =20 >=20 > Martin Dolly > AT&T=20 >=20 > Sent from my iPhone >=20 > On Jun 6, 2013, at 6:15 PM, "Richard Shockey" = wrote: >=20 >> Let=92s be realistic. For the consumer that is being grossly = affected by this problem you are dealing with a class of consumer device = that is, for the time being, is not going to display any type of = reputation information beyond =93unknown=94 even in the enterprise this = is not going to work too well. >> =20 >> I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m = happy to do that. I expect that they can simply manage the service in an = appropriate manner to keep me paying them X per month. We have seen the = failure of DKIM we do not want the Public SIP Telephony Network to end = up like .. >> =20 >> This is going to end up being a service provider problem first then = something else as the SIP/IMS networks evolve. >> =20 >> My life and ours is complicated enough. >> =20 >> Simple wins. >> =20 >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C >> Sent: Thursday, June 06, 2013 5:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] A 4474 that will work through SBCs = (generally/potentially >> =20 >> I agree. But the interface to the user needs to be easily understood = to the user, independent of device. >> =20 >> -----Original Message----- >> From: source-auth@cdt.org [mailto:source-auth@cdt.org] On Behalf Of = Jean-Francois Mule >> Sent: Wednesday, June 05, 2013 1:18 PM >> To: source-auth@cdt.org >> Subject: Re: A 4474 that will work through SBCs = (generally/potentially) >> =20 >> There may exist options for presenting unsigned calls to end-users = and >> allow them to decide on a call rejection. >> =20 >> I would encourage the separation of end-users from service providers = and >> hope the technical solution can enable multiple policies for SSPs and >> regulators to choose from (SIP Service Providers could be = enterprises, >> SMS, service operators, or my asterisk software). >> =20 >> Jean-Francois. >> --- >> Jean-Fran=E7ois Mul=E9 >> Mobile:+1-415-881-7178 >> mailto:jfm@cablelabs.com >> =20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Labs >> md3135@att.com >> +1-609-903-3360 >> =20 >> =20 >> =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_ED32AEEC-6C4F-4172-84C6-FA7EDA1D74F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Since = virtually no bad calls are SIP end to end, it would seem that we need = something that lets us go SIP to PSTN to SIP, early = on.

I do think there are opportunities to show more = info, but I get the point about paying the service provider for a = reliable = service.

Brian

On Jun = 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" <md3135@att.com> wrote:

I agree that only a simple solution that addresses IP space is the = Big Bang for the buck

We might add an extension for authentication = assurance   

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 6, 2013, at 6:15 PM, "Richard Shockey" <richard@shockey.us> wrote:

Let=92s be = realistic.  For the consumer that is being grossly affected by this problem = you are dealing with a class of consumer device that is, for the time = being, is not going to display any type of reputation information beyond  =93unknown=94 even in the = enterprise this is not going to work too well.

 

I pay Verizon = or ATT or Bell Canada or Orange for a service. I=92m happy to do that. I = expect that they can simply manage the service in an appropriate manner = to keep me paying them X per month.  We have seen the failure = of DKIM we do not want the Public SIP Telephony Network to end up like = ..

 

This is going = to end up being a service provider problem first then something else as the = SIP/IMS networks evolve.

 

My life and = ours is complicated enough.

 

Simple wins.

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Thursday, June 06, 2013 5:05 PM
To: stir@ietf.org
Subject: Re: [stir] A 4474 that will work through SBCs = (generally/potentially

 

I agree. But = the interface to the user needs to be easily understood to the user, = independent of device.

 

-----Original Message-----

From: source-auth@cdt.org [mailto:source-auth@cdt.org] On Behalf Of Jean-Francois Mule

Sent: = Wednesday, June 05, 2013 1:18 PM

Subject: Re: = A 4474 that will work through SBCs = (generally/potentially)

 

There may = exist options for presenting unsigned calls to end-users = and

allow them = to decide on a call rejection.

 

I would = encourage the separation of end-users from service providers = and

hope the = technical solution can enable multiple policies for SSPs = and

regulators = to choose from (SIP Service Providers could be = enterprises,

SMS, service = operators, or my asterisk software).

 

Jean-Francois.

---

Jean-Fran=E7ois Mul=E9

Mobile:+1-415-881-7178

 

Martin = Dolly
Lead Member Technical Staff

Core & = Government/Regulatory Standards
AT&T = Labs
md3135@att.com

+1-609-903-3360

 

 

 

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

= --Apple-Mail=_ED32AEEC-6C4F-4172-84C6-FA7EDA1D74F5-- From md3135@att.com Thu Jun 6 15: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 1346A21F8AC2 for ; Thu, 6 Jun 2013 15:50:47 -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 lBcqn9JqQSUU for ; Thu, 6 Jun 2013 15:50:41 -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 67FFC21F8AD5 for ; Thu, 6 Jun 2013 15:50:39 -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 f3211b15.76bbc940.541255.00-590.1492811.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 06 Jun 2013 22:50:39 +0000 (UTC) X-MXL-Hash: 51b1123f419c30d6-301f1a48012d5e5e932cad5f19db1ee0d55dfa2a 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 d3211b15.0.541247.00-100.1492789.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 06 Jun 2013 22:50:38 +0000 (UTC) X-MXL-Hash: 51b1123e3a564742-92387ebdd0a294fe9ff85dde27aa8f581f9a3a03 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 r56MobSg023538; Thu, 6 Jun 2013 18:50:37 -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 r56MoTJG023466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 18:50:32 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 6 Jun 2013 22:50:15 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Thu, 6 Jun 2013 18:50:19 -0400 From: "DOLLY, MARTIN C" To: Brian Rosen Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOYwNq0ALSXDZCyEmtgvtHhkZiE5kpQ/kNgABEIgD//8JN9w== Date: Thu, 6 Jun 2013 22:50:18 +0000 Message-ID: <91248EBA-C1F9-4C9A-8FF3-789BA42CA751@att.com> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com>, <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> In-Reply-To: <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_91248EBAC1F94C9A8FF3789BA42CA751attcom_" 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=a5GHAzuF c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=oOBisLQmZ4cA:10 a=HLLxP2VMAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=yXOkaXPSAAAA:8 a=jU2thFBwAAAA:8 a=5-o_QNGjyj_woTLj] X-AnalysisOut: [W4gA:9 a=pILNOxqGKmIA:10 a=1AMfzNb-s8QA:10 a=qM39cor4HRgA:] X-AnalysisOut: [10 a=-zy3ex45pM4A:10 a=Hz7IrDYlS0cA:10 a=vRAbILRZcFsA:10 a] X-AnalysisOut: [=lZB815dzVvQA:10 a=yDfFGXr2RxwA:10 a=0SpQNr0Kj84A:10 a=Yoy] X-AnalysisOut: [di9cpODXZ80dS:21 a=LACggocRMvt6SkSQ:21 a=QqRBT24o1-qEYBmJQ] X-AnalysisOut: [m4A:9 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:1] X-AnalysisOut: [0 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=jL8Tijzl6uHINtsa:2] X-AnalysisOut: [1 a=U9aA3-kw0TXWnokg:21 a=__4DUFsQeCwwiisG:21] Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 22:50:47 -0000 --_000_91248EBAC1F94C9A8FF3789BA42CA751attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian PSTN is a the icing on the cake BR Martin Dolly AT&T Sent from my iPhone On Jun 6, 2013, at 6:31 PM, "Brian Rosen" > wrote: Since virtually no bad calls are SIP end to end, it would seem that we need= something that lets us go SIP to PSTN to SIP, early on. I do think there are opportunities to show more info, but I get the point a= bout paying the service provider for a reliable service. Brian On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" > wrote: I agree that only a simple solution that addresses IP space is the Big Bang= for the buck We might add an extension for authentication assurance Martin Dolly AT&T Sent from my iPhone On Jun 6, 2013, at 6:15 PM, "Richard Shockey" > wrote: Let=92s be realistic. For the consumer that is being grossly affected by t= his problem you are dealing with a class of consumer device that is, for th= e time being, is not going to display any type of reputation information be= yond =93unknown=94 even in the enterprise this is not going to work too we= ll. I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m happy to= do that. I expect that they can simply manage the service in an appropriat= e manner to keep me paying them X per month. We have seen the failure of D= KIM we do not want the Public SIP Telephony Network to end up like .. This is going to end up being a service provider problem first then somethi= ng else as the SIP/IMS networks evolve. My life and ours is complicated enough. Simple wins. From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Thursday, June 06, 2013 5:05 PM To: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly I agree. But the interface to the user needs to be easily understood to the= user, independent of device. -----Original Message----- From: source-auth@cdt.org [mailto:source-auth@c= dt.org] On Behalf Of Jean-Francois Mule Sent: Wednesday, June 05, 2013 1:18 PM To: source-auth@cdt.org Subject: Re: A 4474 that will work through SBCs (generally/potentially) There may exist options for presenting unsigned calls to end-users and allow them to decide on a call rejection. I would encourage the separation of end-users from service providers and hope the technical solution can enable multiple policies for SSPs and regulators to choose from (SIP Service Providers could be enterprises, SMS, service operators, or my asterisk software). Jean-Francois. --- Jean-Fran=E7ois Mul=E9 Mobile:+1-415-881-7178 mailto:jfm@cablelabs.com Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Labs md3135@att.com +1-609-903-3360 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_91248EBAC1F94C9A8FF3789BA42CA751attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Brian

PSTN is a the icing on the cake 

BR

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 6, 2013, at 6:31 PM, "Brian Rosen" <br@brianrosen.net> wrote:

Since virtually no bad calls are SIP end to end, it would seem that we= need something that lets us go SIP to PSTN to SIP, early on.

I do think there are opportunities to show more info, but I get the po= int about paying the service provider for a reliable service.

Brian

On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" <md3135@att.com> wrote:

I agree that only a simple solution that addresses IP space is the Big= Bang for the buck

We might add an extension for authentication assurance  &nbs= p;

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 6, 2013, at 6:15 PM, "Richard Shockey" <richard@shockey.us> wrote:

Let=92s be realistic.  For the consumer that is being grossly affected by this problem you = are dealing with a class of consumer device that is, for the time being, is= not going to display any type of reputation information beyond  =93unknown=94 even in the ent= erprise this is not going to work too well.

 

I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m happy to do that. I expect t= hat they can simply manage the service in an appropriate manner to keep me = paying them X per month.  We have seen the failure of D= KIM we do not want the Public SIP Telephony Network to end up like ..<= /o:p>

 

This is going to end up being a service provider problem first then something else as the SIP/I= MS networks evolve.

 

My life and ours is complicated enough.

 

Simple wins.

 

From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Thursday, June 06, 2013 5:05 PM
To: stir@ietf.org
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially

 

I agree. But the in= terface to the user needs to be easily understood to the user, independent of device.

 

-----Original Messa= ge-----

From: source-auth@cdt.org [mailto:source-auth@cdt.org= ] On Behalf Of Jean-Francois Mule

Sent: Wednesday, Ju= ne 05, 2013 1:18 PM

To: source-auth@cdt.org<= /span>

Subject: Re: A 4474= that will work through SBCs (generally/potentially)

 

There may exist opt= ions for presenting unsigned calls to end-users and

allow them to decid= e on a call rejection.

 

I would encourage t= he separation of end-users from service providers and

hope the technical = solution can enable multiple policies for SSPs and=

regulators to choos= e from (SIP Service Providers could be enterprises,

SMS, service operat= ors, or my asterisk software).

 

Jean-Francois.=

---

Jean-Fran=E7ois Mul= =E9

Mobile:+1-415-8= 81-7178

mailto:= jfm@cablelabs.com<= /span>

 

Martin Dolly
Lead Member Technical Staff

Core & Governme= nt/Regulatory Standards
AT&T Labs
md3135@att.com

+1-609-903-3360=

 

 

 

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

--_000_91248EBAC1F94C9A8FF3789BA42CA751attcom_-- From pkyzivat@alum.mit.edu Thu Jun 6 15: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 07B0B21F99E0 for ; Thu, 6 Jun 2013 15:55:58 -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 zyD4xi+DgKjb for ; Thu, 6 Jun 2013 15:55:53 -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 2F5A421F99D4 for ; Thu, 6 Jun 2013 15:55:52 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id l7Y41l0170SCNGk5BAvogB; Thu, 06 Jun 2013 22:55:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id lAvn1l00m3ZTu2S3VAvoc4; Thu, 06 Jun 2013 22:55:48 +0000 Message-ID: <51B11373.9050507@alum.mit.edu> Date: Thu, 06 Jun 2013 18:55:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> In-Reply-To: <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.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=1370559348; bh=2vXkq4/m1hnDy89YQ8riAXLvg37j43k8NedqWVAa8w8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FAANiblbWlRhEdplEVmpGSCZ1LmJJdaXtwXCWXeyC+U4hx3pV0F1iu650UksbgUlD l8o4j1BWeIKLVQUwroTu3oaeQMtEH5jSKZNiRDMTb1yRyDNava9EY/akUmCdBl3f/y fXYqmAkLtzmyELVUR+Rf/yNHeHY4M2VOh8Wf172uvFTKUch03VLNycc2Tjg1Bm/vPa xyFoO+QBn7un2bdQAxjzD3g3GFF7hTCHwkOk+8bhELRZOJVAQKD947vw4MgoYwLUMl PNzstTm3VMRvFkzI/hs+t5rfVLdtpbWPlIopPIdqDMtkf6sA+h0Tg6QTFkLs/K4amO dt1t6MHZDfZGg== Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 22:55:58 -0000 On 6/6/13 6:31 PM, Brian Rosen wrote: > Since virtually no bad calls are SIP end to end, No? Why? Just lack of demand? Or lack of technology? > it would seem that we > need something that lets us go SIP to PSTN to SIP, early on. For PSTN to SIP, the sip side has nothing better to go on than what it was provided. So it seems the only option here is transitive trust. Now consider a "trusted" PSTN source. It can't remain trusted if it permits spoofed IDs on its incoming SIP connections. So such a SIP-PSTN interconnect must not assert an ID for any call it gets from a sip source and can't verify. So ISTM that in addition to a suitable mechanism, there is need for a certification process for PSTN providers that they are suitably verifying incoming sip calls. Thanks, Paul > I do think there are opportunities to show more info, but I get the > point about paying the service provider for a reliable service. > > Brian > > On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" > wrote: > >> I agree that only a simple solution that addresses IP space is the Big >> Bang for the buck >> >> We might add an extension for authentication assurance >> >> Martin Dolly >> AT&T >> >> Sent from my iPhone >> >> On Jun 6, 2013, at 6:15 PM, "Richard Shockey" > > wrote: >> >>> Let’s be realistic.For the consumer that is being grossly affected by >>> this problem you are dealing with a class of consumer device that is, >>> for the time being, is not going to display any type of reputation >>> information beyond “unknown” even in the enterprise this is not going >>> to work too well. >>> >>> I pay Verizon or ATT or Bell Canada or Orange for a service. I’m >>> happy to do that. I expect that they can simply manage the service in >>> an appropriate manner to keep me paying them X per month. We have >>> seen the failure of DKIM we do not want the Public SIP Telephony >>> Network to end up like .. >>> >>> This is going to end up being a service provider problem first then >>> something else as the SIP/IMS networks evolve. >>> >>> My life and ours is complicated enough. >>> >>> Simple wins. >>> >>> *From:*stir-bounces@ietf.org >>> [mailto:stir-bounces@ietf.org] *On Behalf Of *DOLLY, MARTIN C >>> *Sent:* Thursday, June 06, 2013 5:05 PM >>> *To:* stir@ietf.org >>> *Subject:* Re: [stir] A 4474 that will work through SBCs >>> (generally/potentially >>> >>> I agree. But the interface to the user needs to be easily understood >>> to the user, independent of device. >>> >>> -----Original Message----- >>> >>> From: >>> source-auth@cdt.org[mailto:source-auth@cdt.org] >>> On Behalf Of Jean-Francois Mule >>> >>> Sent: Wednesday, June 05, 2013 1:18 PM >>> >>> To: source-auth@cdt.org >>> >>> Subject: Re: A 4474 that will work through SBCs (generally/potentially) >>> >>> There may exist options for presenting unsigned calls to end-users and >>> >>> allow them to decide on a call rejection. >>> >>> I would encourage the separation of end-users from service providers and >>> >>> hope the technical solution can enable multiple policies for SSPs and >>> >>> regulators to choose from (SIP Service Providers could be enterprises, >>> >>> SMS, service operators, or my asterisk software). >>> >>> Jean-Francois. >>> >>> --- >>> >>> Jean-François Mulé >>> >>> Mobile:+1-415-881-7178 >>> >>> mailto:jfm@cablelabs.com >>> >>> Martin Dolly >>> Lead Member Technical Staff >>> >>> Core & Government/Regulatory Standards >>> AT&T Labs >>> md3135@att.com >>> >>> +1-609-903-3360 >>> >> _______________________________________________ >> 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 Jun 6 16:03: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 703CC11E80A2 for ; Thu, 6 Jun 2013 16:03:34 -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=[AWL=0.001, 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 Y3P4hpmNihPn for ; Thu, 6 Jun 2013 16:03:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 813E021F998B for ; Thu, 6 Jun 2013 16:03:28 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 04511b15.7ec3a940.512053.00-517.1422465.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 06 Jun 2013 23:03:28 +0000 (UTC) X-MXL-Hash: 51b115405fb0e388-ed9d441d7b82b893d1b140b5866b027dace88cbb Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 33511b15.0.511934.00-383.1422093.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 06 Jun 2013 23:03:16 +0000 (UTC) X-MXL-Hash: 51b11534164ea4d6-a25b0023ff187a33b52d5999c3a05a918d9c8462 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 r56N3D81001295; Thu, 6 Jun 2013 19:03:15 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r56N33Z6001056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 19:03:09 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 6 Jun 2013 23:02:53 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, 6 Jun 2013 19:02:56 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOYwNq0ALSXDZCyEmtgvtHhkZiE5kpQ/kNgABEIgCAAAbjgP//vvI7 Date: Thu, 6 Jun 2013 23:02:56 +0000 Message-ID: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net>, <51B11373.9050507@alum.mit.edu> In-Reply-To: <51B11373.9050507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=f6r/8pOM c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=oOBisLQmZ4cA:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=yXOkaXPSAAAA:8 a=jU2thFBwAAAA:8 a=-5iwgDVpq9pCFTU] X-AnalysisOut: [hxSEA:9 a=pILNOxqGKmIA:10 a=1AMfzNb-s8QA:10 a=qM39cor4HRgA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=vRAbILRZcFsA:10 a=lZB815dzVvQA:10 ] X-AnalysisOut: [a=yDfFGXr2RxwA:10 a=0SpQNr0Kj84A:10 a=yWbcD7d-uw_mMrsh:21 ] X-AnalysisOut: [a=BvK0lGnuqxrMVmTh:21] Cc: "stir@ietf.org" Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 23:03:34 -0000 I rarely agree with Paul, but yes Martin Dolly AT&T=20 Sent from my iPhone On Jun 6, 2013, at 6:56 PM, "Paul Kyzivat" wrote: > On 6/6/13 6:31 PM, Brian Rosen wrote: >> Since virtually no bad calls are SIP end to end, >=20 > No? Why? Just lack of demand? Or lack of technology? >=20 >> it would seem that we >> need something that lets us go SIP to PSTN to SIP, early on. >=20 > For PSTN to SIP, the sip side has nothing better to go on than what it wa= s provided. So it seems the only option here is transitive trust. >=20 > Now consider a "trusted" PSTN source. It can't remain trusted if it permi= ts spoofed IDs on its incoming SIP connections. So such a SIP-PSTN intercon= nect must not assert an ID for any call it gets from a sip source and can't= verify. >=20 > So ISTM that in addition to a suitable mechanism, there is need for a cer= tification process for PSTN providers that they are suitably verifying inco= ming sip calls. >=20 > Thanks, > Paul >=20 >> I do think there are opportunities to show more info, but I get the >> point about paying the service provider for a reliable service. >>=20 >> Brian >>=20 >> On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" > > wrote: >>=20 >>> I agree that only a simple solution that addresses IP space is the Big >>> Bang for the buck >>>=20 >>> We might add an extension for authentication assurance >>>=20 >>> Martin Dolly >>> AT&T >>>=20 >>> Sent from my iPhone >>>=20 >>> On Jun 6, 2013, at 6:15 PM, "Richard Shockey" >> > wrote: >>>=20 >>>> Let=92s be realistic.For the consumer that is being grossly affected b= y >>>> this problem you are dealing with a class of consumer device that is, >>>> for the time being, is not going to display any type of reputation >>>> information beyond =93unknown=94 even in the enterprise this is not go= ing >>>> to work too well. >>>>=20 >>>> I pay Verizon or ATT or Bell Canada or Orange for a service. I=92m >>>> happy to do that. I expect that they can simply manage the service in >>>> an appropriate manner to keep me paying them X per month. We have >>>> seen the failure of DKIM we do not want the Public SIP Telephony >>>> Network to end up like .. >>>>=20 >>>> This is going to end up being a service provider problem first then >>>> something else as the SIP/IMS networks evolve. >>>>=20 >>>> My life and ours is complicated enough. >>>>=20 >>>> Simple wins. >>>>=20 >>>> *From:*stir-bounces@ietf.org >>>> [mailto:stir-bounces@ietf.org] *On Behalf Of *DOLLY, MARTIN C >>>> *Sent:* Thursday, June 06, 2013 5:05 PM >>>> *To:* stir@ietf.org >>>> *Subject:* Re: [stir] A 4474 that will work through SBCs >>>> (generally/potentially >>>>=20 >>>> I agree. But the interface to the user needs to be easily understood >>>> to the user, independent of device. >>>>=20 >>>> -----Original Message----- >>>>=20 >>>> From: >>>> source-auth@cdt.org[mailto:source-auth@cdt= .org] >>>> On Behalf Of Jean-Francois Mule >>>>=20 >>>> Sent: Wednesday, June 05, 2013 1:18 PM >>>>=20 >>>> To: source-auth@cdt.org >>>>=20 >>>> Subject: Re: A 4474 that will work through SBCs (generally/potentially= ) >>>>=20 >>>> There may exist options for presenting unsigned calls to end-users and >>>>=20 >>>> allow them to decide on a call rejection. >>>>=20 >>>> I would encourage the separation of end-users from service providers a= nd >>>>=20 >>>> hope the technical solution can enable multiple policies for SSPs and >>>>=20 >>>> regulators to choose from (SIP Service Providers could be enterprises, >>>>=20 >>>> SMS, service operators, or my asterisk software). >>>>=20 >>>> Jean-Francois. >>>>=20 >>>> --- >>>>=20 >>>> Jean-Fran=E7ois Mul=E9 >>>>=20 >>>> Mobile:+1-415-881-7178 >>>>=20 >>>> mailto:jfm@cablelabs.com >>>>=20 >>>> Martin Dolly >>>> Lead Member Technical Staff >>>>=20 >>>> Core & Government/Regulatory Standards >>>> AT&T Labs >>>> md3135@att.com >>>>=20 >>>> +1-609-903-3360 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=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 hadriel.kaplan@oracle.com Thu Jun 6 16:13: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 B456921E8064 for ; Thu, 6 Jun 2013 16:13:59 -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 qmch+D5IpLiu for ; Thu, 6 Jun 2013 16:13:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9D33421E8053 for ; Thu, 6 Jun 2013 16:13:50 -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 r56NDjgc004761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 23:13:46 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 r56NDiGE016333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 23:13:44 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 r56NDi0l016325; Thu, 6 Jun 2013 23:13:44 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 16:13: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: <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> Date: Thu, 6 Jun 2013 19:13:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 06 Jun 2013 23:14:00 -0000 On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: > Since virtually no bad calls are SIP end to end, it would seem that we = need something that lets us go SIP to PSTN to SIP, early on. If virtually no bad calls are SIP the whole way, then identifying which = calls are SIP the whole way will tell you when the calls are good. ;) (ie, using an authentication mechanism which works when calls are SIP = the whole way might not be such a bad thing... it just won't tell you = when legacy-PSTN-based calls are also good) That's all we were really going to accomplish anyway - identify good = caller-ids, not identify bad ones. By that I mean it's not like there = was going to be a flag day when suddenly everyone everywhere switches to = doing some new caller-id mechanism; so instead we'd only be able to = identify legitimate caller-ids for a portion of the calls, and the rest = would basically be "unverified" or whatever. So only the very "good = guys" are going to be using this mechanism at first for a while anyway, = and they generally use SIP a lot already. It might be reasonable to expect the adoption rate of a new caller-id = auth mechanism to follow the adoption rate of SIP interconnection, at = least within the US/NANP (which is what started this topic). -hadriel From br@brianrosen.net Thu Jun 6 17:35: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 0F69721F93E1 for ; Thu, 6 Jun 2013 17:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Kq3SY5PZG5JA for ; Thu, 6 Jun 2013 17:35:38 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id C7BA521F8C40 for ; Thu, 6 Jun 2013 17:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=EU7iaizHPd5x26bfTyca9Gc9YdDohaOeyglHaVAQP+w=; b=ZCK8ypYmg1UVoIIwjvCZOtsZziw104cbZv5EaWK1Kkf7EUnxLkhWLoN0uDSR+PasQ5IiokKREpJOiFqLIILzhXlRD77Uht4jsTUCOxEr51QgtbXOyx/gsqqghhwPLOaPVfFN9ctjcH9hn8mwpKOx/xec/TtsCE/XD/ff2FRD87s=; Received: from neustargw.va.neustar.com ([209.173.53.233]:32142 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UkkeW-00079V-Mt; Thu, 06 Jun 2013 20:35:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: Date: Thu, 6 Jun 2013 20:35:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 00:35:43 -0000 The problem we're trying to solve has one end (the origination end) = mostly on SIP and the termination end mostly on PSTN/2G/3G with, = commonly, two or more transitions. The origination end is mostly SIP because it's much much easier to = manipulate the signaling. The service providers that are tolerant of = the problems are SIP service providers. They are mostly = non-certificated carriers, which means they have to go through someone = else to get to the termination network, because nearly all of the = interconnects today are SS7. You often see 3 or more SIP providers, = then an SS7 transition, then, increasingly, a conversion back to SIP, = and finally the termination endpoint, which today is heavily weighted = POTS or 2G./3G wireless, but increasingly is SIP based. If the endpoint = is enterprise, it's better. It's getting to all SIP on the termination = side quickly, but there is still an SS7 link between origination and = termination. We can't deploy today, but if we try to deploy, say next year, then we = can't assume most carrier interconnect is SIP. Wish it were true, = isn't. Increasingly, there is a SIP leg in the termination side, and I = think if we make things work so we get that environment (SIP on = origination, at least one SIP leg in termination, SS7 between = origination and termination), we will largely address the problems. It = will get better as more legs migrate to SIP, but if it has to be SIP end = to end before the problem is addressed, what we are attempting will be = considered a fail. If we make the mostly-but-not-all SIP scenario largely true, we will = most likely also help the case where there isn't (yet) a SIP leg on the = termination side, only because we will have enough disincentive in place = so the problem sources will mostly be stymied. If at least one SIP leg = only accepts calls with a validated identity we can fix a lot of the = problem. So, there is a continuum: If one leg on the origination side checks, we get the first real value, = and it's substantial If one leg on the termination side checks, and we have SIP interconnect = to that point, we have more value If one leg on the termination side checks, and it works across an SS7 = interconnect, we have a great deal of value If we get end to end checks, we get to where we want to be eventually The longer it takes to deploy, the more SIP interconnects there are and = the value of a mechanism that works around the SS7 interconnect fades. = We're really trying to make a really significant dent in the problem = well before we expect that to happen, which is why I think having some = mechanism to work around an SS7 leg is going to be important. But, there is no doubt that if we just get one leg in the origination = side to check, we get a big win. Brian On Jun 6, 2013, at 7:13 PM, Hadriel Kaplan = wrote: >=20 > On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: >=20 >> Since virtually no bad calls are SIP end to end, it would seem that = we need something that lets us go SIP to PSTN to SIP, early on. >=20 > If virtually no bad calls are SIP the whole way, then identifying = which calls are SIP the whole way will tell you when the calls are good. = ;) >=20 > (ie, using an authentication mechanism which works when calls are SIP = the whole way might not be such a bad thing... it just won't tell you = when legacy-PSTN-based calls are also good) >=20 > That's all we were really going to accomplish anyway - identify good = caller-ids, not identify bad ones. By that I mean it's not like there = was going to be a flag day when suddenly everyone everywhere switches to = doing some new caller-id mechanism; so instead we'd only be able to = identify legitimate caller-ids for a portion of the calls, and the rest = would basically be "unverified" or whatever. So only the very "good = guys" are going to be using this mechanism at first for a while anyway, = and they generally use SIP a lot already. >=20 > It might be reasonable to expect the adoption rate of a new caller-id = auth mechanism to follow the adoption rate of SIP interconnection, at = least within the US/NANP (which is what started this topic). >=20 > -hadriel >=20 From hgs@cs.columbia.edu Thu Jun 6 19: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 E81281F0D2F for ; Thu, 6 Jun 2013 19:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_84=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 4VNE6QVRjex3 for ; Thu, 6 Jun 2013 19:16:28 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id D594121F9476 for ; Thu, 6 Jun 2013 19:16:25 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r572GNAR006018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 6 Jun 2013 22:16:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: Henning Schulzrinne In-Reply-To: Date: Thu, 6 Jun 2013 22:16:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3732E7-63CC-4D29-B851-58F2805AB4A0@cs.columbia.edu> References: To: stir@ietf.org X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 02:16:34 -0000 I was thinking of the latter - add something to the textual display to = indicate trust. On Jun 6, 2013, at 6:02 PM, Hadriel Kaplan wrote: >=20 > If you mean the terminal-adapter/gateway inserting the extra character = onto the caller-id sent on the POTS line itself (ie, in the FSK), then I = think it would screw up some POTS phones that try to match received CID = to their local address books, or that provide a local call-back feature. = (my POTS phone at home does both of those things, for example) >=20 > But for the callerid+name type POTS lines (ie, MDMF type as opposed to = SMDF) you could put a character in the name string if there's room, = instead of in the number field. >=20 > -hadriel >=20 >=20 > On Jun 6, 2013, at 5:09 PM, "Rosen, Brian" > wrote: >=20 >> This is a case where a smarter device could be attractive, rather = than a POTS telephone (through a terminal adapter). Smarter devices = could display information that told the user more about the call. >>=20 >> While I don't see POTS service Caller-Id changing, you could imagine = having a TAD that checked the sig and put a character in front of the = name/number that was a good/bad/no data indicator of the sig check. >>=20 >> Brian >> On Jun 6, 2013, at 5:03 PM, "DOLLY, MARTIN C" >> wrote: >>=20 >>> I agree. But the interface to the user needs to be easily understood = to the user, independent of device. >>>=20 >>> -----Original Message----- >>> From: source-auth@cdt.org [mailto:source-auth@cdt.org] On Behalf Of = Jean-Francois Mule >>> Sent: Wednesday, June 05, 2013 1:18 PM >>> To: source-auth@cdt.org >>> Subject: Re: A 4474 that will work through SBCs = (generally/potentially) >>>=20 >>> There may exist options for presenting unsigned calls to end-users = and >>> allow them to decide on a call rejection. >>>=20 >>> I would encourage the separation of end-users from service providers = and >>> hope the technical solution can enable multiple policies for SSPs = and >>> regulators to choose from (SIP Service Providers could be = enterprises, >>> SMS, service operators, or my asterisk software). >>>=20 >>> Jean-Francois. >>> --- >>> Jean-Fran=E7ois Mul=E9 >>> Mobile:+1-415-881-7178 >>> mailto:jfm@cablelabs.com >>>=20 >>>=20 >>>=20 >>> On 06/05/2013 08:13, "Henning Schulzrinne" = wrote: >>>=20 >>>> You might want to start to have that discussion with your public = policy >>>> folks soon. I'd be happy to facilitate meetings on this topic as = needed. >>>> There are intermediate steps, beyond blanket rejection, such as = rejecting >>>> calls where the number is in the "must be signed list" and the call >>>> isn't. This deals with a lot of worst kinds of impersonation = abuses. >>>>=20 >>>> On Jun 5, 2013, at 8:54 AM, "DOLLY, MARTIN C" = wrote: >>>>=20 >>>>> I "believe" that we (Tier 1/2) would need some permission = (regulation) >>>>> to not accept unsigned calls. >>>>>=20 >>>>> On the other hand, what is grandma is calling from one of those = smaller >>>>> providers, if we do not forward those calls to the destination, = our >>>>> customer will complain. >>>>=20 >>>>=20 >>>>=20 >>>> ############################################################# >>>> This message is sent to you because you are subscribed to >>>> the mailing list . >>>> To unsubscribe, E-mail to: >>>> To switch to the DIGEST mode, E-mail to = >>>> To switch to the INDEX mode, E-mail to >>>> Send administrative queries to >>>>=20 >>>=20 >>>=20 >>>=20 >>> ############################################################# >>> This message is sent to you because you are subscribed to >>> the mailing list . >>> To unsubscribe, E-mail to: >>> To switch to the DIGEST mode, E-mail to >>> To switch to the INDEX mode, E-mail to >>> Send administrative queries to >>>=20 >>>=20 >>>=20 >>> ############################################################# >>> This message is sent to you because you are subscribed to >>> the mailing list . >>> To unsubscribe, E-mail to: >>> To switch to the DIGEST mode, E-mail to >>> To switch to the INDEX mode, E-mail to >>> Send administrative queries to >>>=20 >>=20 >>=20 >>=20 >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> To switch to the DIGEST mode, E-mail to >> To switch to the INDEX mode, E-mail to >> Send administrative queries to >>=20 >=20 >=20 >=20 > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to > To switch to the INDEX mode, E-mail to > Send administrative queries to >=20 >=20 From hgs@cs.columbia.edu Thu Jun 6 19:38: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 7BC8421F91AB for ; Thu, 6 Jun 2013 19:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 vk69jWG-BcDV for ; Thu, 6 Jun 2013 19:38:34 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6B21F9121 for ; Thu, 6 Jun 2013 19:38:34 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r572cSd6026562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 22:38:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> Date: Thu, 6 Jun 2013 22:38:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "stir@ietf.org" , Hadriel Kaplan , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 02:38:39 -0000 My take is that the first SS7 carrier tends to be trusted (and = trustworthy), and should be able to mark or drop bad-actor calls. (The = former might involve a new calling party category. Or you could use the = prison phone category, anticipating future residential address of the = caller.) On Jun 6, 2013, at 8:35 PM, Brian Rosen wrote: > The problem we're trying to solve has one end (the origination end) = mostly on SIP and the termination end mostly on PSTN/2G/3G with, = commonly, two or more transitions. >=20 > The origination end is mostly SIP because it's much much easier to = manipulate the signaling. The service providers that are tolerant of = the problems are SIP service providers. They are mostly = non-certificated carriers, which means they have to go through someone = else to get to the termination network, because nearly all of the = interconnects today are SS7. You often see 3 or more SIP providers, = then an SS7 transition, then, increasingly, a conversion back to SIP, = and finally the termination endpoint, which today is heavily weighted = POTS or 2G./3G wireless, but increasingly is SIP based. If the endpoint = is enterprise, it's better. It's getting to all SIP on the termination = side quickly, but there is still an SS7 link between origination and = termination. >=20 > We can't deploy today, but if we try to deploy, say next year, then we = can't assume most carrier interconnect is SIP. Wish it were true, = isn't. Increasingly, there is a SIP leg in the termination side, and I = think if we make things work so we get that environment (SIP on = origination, at least one SIP leg in termination, SS7 between = origination and termination), we will largely address the problems. It = will get better as more legs migrate to SIP, but if it has to be SIP end = to end before the problem is addressed, what we are attempting will be = considered a fail. >=20 > If we make the mostly-but-not-all SIP scenario largely true, we will = most likely also help the case where there isn't (yet) a SIP leg on the = termination side, only because we will have enough disincentive in place = so the problem sources will mostly be stymied. If at least one SIP leg = only accepts calls with a validated identity we can fix a lot of the = problem. >=20 > So, there is a continuum: > If one leg on the origination side checks, we get the first real = value, and it's substantial > If one leg on the termination side checks, and we have SIP = interconnect to that point, we have more value > If one leg on the termination side checks, and it works across an SS7 = interconnect, we have a great deal of value > If we get end to end checks, we get to where we want to be eventually >=20 > The longer it takes to deploy, the more SIP interconnects there are = and the value of a mechanism that works around the SS7 interconnect = fades. We're really trying to make a really significant dent in the = problem well before we expect that to happen, which is why I think = having some mechanism to work around an SS7 leg is going to be = important. >=20 > But, there is no doubt that if we just get one leg in the origination = side to check, we get a big win. >=20 > Brian >=20 > On Jun 6, 2013, at 7:13 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: >>=20 >>> Since virtually no bad calls are SIP end to end, it would seem that = we need something that lets us go SIP to PSTN to SIP, early on. >>=20 >> If virtually no bad calls are SIP the whole way, then identifying = which calls are SIP the whole way will tell you when the calls are good. = ;) >>=20 >> (ie, using an authentication mechanism which works when calls are SIP = the whole way might not be such a bad thing... it just won't tell you = when legacy-PSTN-based calls are also good) >>=20 >> That's all we were really going to accomplish anyway - identify good = caller-ids, not identify bad ones. By that I mean it's not like there = was going to be a flag day when suddenly everyone everywhere switches to = doing some new caller-id mechanism; so instead we'd only be able to = identify legitimate caller-ids for a portion of the calls, and the rest = would basically be "unverified" or whatever. So only the very "good = guys" are going to be using this mechanism at first for a while anyway, = and they generally use SIP a lot already. >>=20 >> It might be reasonable to expect the adoption rate of a new caller-id = auth mechanism to follow the adoption rate of SIP interconnection, at = least within the US/NANP (which is what started this topic). >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From dhc2@dcrocker.net Thu Jun 6 20:30: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 7DE0F21E804B for ; Thu, 6 Jun 2013 20:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihpyBCpuHQKO for ; Thu, 6 Jun 2013 20:30:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 944DD11E80BA for ; Thu, 6 Jun 2013 20:30:09 -0700 (PDT) Received: from [192.168.1.7] (chello080108132236.14.wu-wien.teleweb.at [80.108.132.236] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r573TvYb008373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 20:30:05 -0700 Message-ID: <51B153B2.9080402@dcrocker.net> Date: Fri, 07 Jun 2013 05:29:54 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Shockey References: <005401ce6303$61afdc90$250f95b0$@shockey.us> In-Reply-To: <005401ce6303$61afdc90$250f95b0$@shockey.us> 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, 06 Jun 2013 20:30:07 -0700 (PDT) Cc: stir@ietf.org, "'DOLLY, MARTIN C'" Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially 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: Fri, 07 Jun 2013 03:30:14 -0000 On 6/7/2013 12:15 AM, Richard Shockey wrote: > We have seen the failure of DKIM Huh? What failure? DKIM isn't for end-users, so I really don't understand what you mean. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Thu Jun 6 20:42: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 C574221F87FB for ; Thu, 6 Jun 2013 20:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIn3AtLjNIXP for ; Thu, 6 Jun 2013 20:42:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4BD021F87E1 for ; Thu, 6 Jun 2013 20:42:02 -0700 (PDT) Received: from [192.168.1.7] (chello080108132236.14.wu-wien.teleweb.at [80.108.132.236] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r573fnsQ008616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 20:41:55 -0700 Message-ID: <51B15679.7060401@dcrocker.net> Date: Fri, 07 Jun 2013 05:41:45 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <2D3732E7-63CC-4D29-B851-58F2805AB4A0@cs.columbia.edu> In-Reply-To: <2D3732E7-63CC-4D29-B851-58F2805AB4A0@cs.columbia.edu> 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, 06 Jun 2013 20:41:55 -0700 (PDT) Cc: stir@ietf.org Subject: [stir] Displaying a trust indicator (was: Re: A 4474 that will work through SBCs (generally/potentially)) 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: Fri, 07 Jun 2013 03:42:15 -0000 On 6/7/2013 4:16 AM, Henning Schulzrinne wrote: > I was thinking of the latter - add something to the textual display to indicate trust. The human factors design issues that the suggestion invokes unfortunately are far more challenging and far less reliable than anyone would wish. At the least, it's a topic that calls on UX/HCI expertise, rather than protocol design expertise. They are very, very different domains of knowledge. As a touchstone, I'll note that it's reasonable to assume that it's good to always give more information, but the assumption is wrong. The dominant model in use for Internet anti-abuse work on adding trust-related mechanisms is to target use by filtering engines by a handling agent (possibly including the receiving user agent, but out of sight of the actual user.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Fri Jun 7 03:35: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 1BDDC21F9371 for ; Fri, 7 Jun 2013 03:35:09 -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, 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 8poQsfmmRW+Z for ; Fri, 7 Jun 2013 03:35:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EAFC821F9246 for ; Fri, 7 Jun 2013 03:35:02 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 99BC826525A; Fri, 7 Jun 2013 12:35:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7A0564C05D; Fri, 7 Jun 2013 12:35:01 +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; Fri, 7 Jun 2013 12:35:01 +0200 From: To: Hadriel Kaplan , "stir@ietf.org" Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: Ac5i+XNhJSk7jFNtS4eNiIdS3GjNjf//8lMAgAADP4CAAAETAIAAC+UA//8wvNA= Date: Fri, 7 Jun 2013 10:35:01 +0000 Message-ID: <31774_1370601301_51B1B755_31774_771_1_B5939C6860701C49AA39C5DA5189448B0A2132@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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.5.21.113319 Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 10:35:09 -0000 > It might be reasonable to expect the adoption rate of a new caller-id aut= h mechanism to follow the > adoption rate of SIP interconnection, at least within the US/NANP (which = is what started this topic). It's an (optimistic, still...) assumption you can probably make elsewhere a= s well. But, if as I would expect, this mechanism depends on the ability to= "sign a number" within national numbering plans anyway, or maybe parts of = these, the adoption rate (and success) of this would also follow the deploy= ment of this capability nationally. This may significantly vary from countr= y to country.=20=20 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 Had= riel Kaplan Sent: Friday, June 07, 2013 1:14 AM To: Brian Rosen Cc: stir@ietf.org; DOLLY, MARTIN C; Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: > Since virtually no bad calls are SIP end to end, it would seem that we ne= ed something that lets us go SIP to PSTN to SIP, early on. If virtually no bad calls are SIP the whole way, then identifying which cal= ls are SIP the whole way will tell you when the calls are good. ;) (ie, using an authentication mechanism which works when calls are SIP the w= hole way might not be such a bad thing... it just won't tell you when legac= y-PSTN-based calls are also good) That's all we were really going to accomplish anyway - identify good caller= -ids, not identify bad ones. By that I mean it's not like there was going = to be a flag day when suddenly everyone everywhere switches to doing some n= ew caller-id mechanism; so instead we'd only be able to identify legitimate= caller-ids for a portion of the calls, and the rest would basically be "un= verified" or whatever. So only the very "good guys" are going to be using = this mechanism at first for a while anyway, and they generally use SIP a lo= t already. It might be reasonable to expect the adoption rate of a new caller-id auth = mechanism to follow the adoption rate of SIP interconnection, at least with= in the US/NANP (which is what started this topic). -hadriel _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From br@brianrosen.net Fri Jun 7 06:00: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 8708421F8F87 for ; Fri, 7 Jun 2013 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 1hO0pnGwYTWz for ; Fri, 7 Jun 2013 06:00:27 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9FE21F8ECB for ; Fri, 7 Jun 2013 06:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=nvGEA4acpIBJ8Pz8YaCBDd/LT9htU/xFmZ9zlY18XUc=; b=EfwPlb8ldrzUvbejW5ta0HXhnO+svxjtwMGuCdqJkLOR0sX5xOfeWkEYPN4AXB/ez9mXUOXBQHxPIEC0W/CXpgbzUgQ9cF4CxjjQO50aB3w+7/UiyHWDxolQ3b9YROtmad9OI3AOI/wq3u0C2D3ApnWN4u+2ehHGfbO06MeNmXM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42421 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UkwHG-00079z-Kf; Fri, 07 Jun 2013 09:00:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: Date: Fri, 7 Jun 2013 09:00:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Hadriel Kaplan , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 13:00:31 -0000 Yeah, that's "one leg on the origination side", and I agree with you. "Drop" is what we're after, but at that point (just before diving into = the SS7 network), we're talking about a certificated carrier who has = restrictions on what calls he can drop, so regulatory action would be = needed in most countries. It might well be fairly forthcoming given the = scale of the problems in many countries. "Mark" may be challenging. It = might be possible to do something in the SS7 signaling that doesn't = change a lot of hardware carriers will not invest in, but at the very = least, you would have to upgrade software in the gateways. The problem, = ISTM, is that unless there is a SIP leg on the other side, there isn't = any reasonable way to detect the mark and do something with it. But, if = there is a SIP leg, then we could do an out of band solution rather than = mark the SS7 signaling. That might be more palatable to the carriers = who really don't want to make any investments in any part of the SS7 = network. Brian On Jun 6, 2013, at 10:38 PM, Henning Schulzrinne = wrote: > My take is that the first SS7 carrier tends to be trusted (and = trustworthy), and should be able to mark or drop bad-actor calls. (The = former might involve a new calling party category. Or you could use the = prison phone category, anticipating future residential address of the = caller.) >=20 > On Jun 6, 2013, at 8:35 PM, Brian Rosen wrote: >=20 >> The problem we're trying to solve has one end (the origination end) = mostly on SIP and the termination end mostly on PSTN/2G/3G with, = commonly, two or more transitions. >>=20 >> The origination end is mostly SIP because it's much much easier to = manipulate the signaling. The service providers that are tolerant of = the problems are SIP service providers. They are mostly = non-certificated carriers, which means they have to go through someone = else to get to the termination network, because nearly all of the = interconnects today are SS7. You often see 3 or more SIP providers, = then an SS7 transition, then, increasingly, a conversion back to SIP, = and finally the termination endpoint, which today is heavily weighted = POTS or 2G./3G wireless, but increasingly is SIP based. If the endpoint = is enterprise, it's better. It's getting to all SIP on the termination = side quickly, but there is still an SS7 link between origination and = termination. >>=20 >> We can't deploy today, but if we try to deploy, say next year, then = we can't assume most carrier interconnect is SIP. Wish it were true, = isn't. Increasingly, there is a SIP leg in the termination side, and I = think if we make things work so we get that environment (SIP on = origination, at least one SIP leg in termination, SS7 between = origination and termination), we will largely address the problems. It = will get better as more legs migrate to SIP, but if it has to be SIP end = to end before the problem is addressed, what we are attempting will be = considered a fail. >>=20 >> If we make the mostly-but-not-all SIP scenario largely true, we will = most likely also help the case where there isn't (yet) a SIP leg on the = termination side, only because we will have enough disincentive in place = so the problem sources will mostly be stymied. If at least one SIP leg = only accepts calls with a validated identity we can fix a lot of the = problem. >>=20 >> So, there is a continuum: >> If one leg on the origination side checks, we get the first real = value, and it's substantial >> If one leg on the termination side checks, and we have SIP = interconnect to that point, we have more value >> If one leg on the termination side checks, and it works across an SS7 = interconnect, we have a great deal of value >> If we get end to end checks, we get to where we want to be eventually >>=20 >> The longer it takes to deploy, the more SIP interconnects there are = and the value of a mechanism that works around the SS7 interconnect = fades. We're really trying to make a really significant dent in the = problem well before we expect that to happen, which is why I think = having some mechanism to work around an SS7 leg is going to be = important. >>=20 >> But, there is no doubt that if we just get one leg in the origination = side to check, we get a big win. >>=20 >> Brian >>=20 >> On Jun 6, 2013, at 7:13 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: >>>=20 >>>> Since virtually no bad calls are SIP end to end, it would seem that = we need something that lets us go SIP to PSTN to SIP, early on. >>>=20 >>> If virtually no bad calls are SIP the whole way, then identifying = which calls are SIP the whole way will tell you when the calls are good. = ;) >>>=20 >>> (ie, using an authentication mechanism which works when calls are = SIP the whole way might not be such a bad thing... it just won't tell = you when legacy-PSTN-based calls are also good) >>>=20 >>> That's all we were really going to accomplish anyway - identify good = caller-ids, not identify bad ones. By that I mean it's not like there = was going to be a flag day when suddenly everyone everywhere switches to = doing some new caller-id mechanism; so instead we'd only be able to = identify legitimate caller-ids for a portion of the calls, and the rest = would basically be "unverified" or whatever. So only the very "good = guys" are going to be using this mechanism at first for a while anyway, = and they generally use SIP a lot already. >>>=20 >>> It might be reasonable to expect the adoption rate of a new = caller-id auth mechanism to follow the adoption rate of SIP = interconnection, at least within the US/NANP (which is what started this = topic). >>>=20 >>> -hadriel >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >=20 From york@isoc.org Fri Jun 7 06:02: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 5F29521F8F6E for ; Fri, 7 Jun 2013 06:02:04 -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 mK8LgEEQ0n9s for ; Fri, 7 Jun 2013 06:02:00 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9192521F8BF9 for ; Fri, 7 Jun 2013 06:01:59 -0700 (PDT) Received: from mail174-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE016.bigfish.com (10.174.4.79) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Jun 2013 13:01:57 +0000 Received: from mail174-db8 (localhost [127.0.0.1]) by mail174-db8-R.bigfish.com (Postfix) with ESMTP id 6F4FAC0379; Fri, 7 Jun 2013 13:01:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL177df4h17326ah8275bh8275dhz2dh2a8h668h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail174-db8 (localhost.localdomain [127.0.0.1]) by mail174-db8 (MessageSwitch) id 137061011561584_12435; Fri, 7 Jun 2013 13:01:55 +0000 (UTC) Received: from DB8EHSMHS019.bigfish.com (unknown [10.174.8.246]) by mail174-db8.bigfish.com (Postfix) with ESMTP id 036B418004F; Fri, 7 Jun 2013 13:01:55 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by DB8EHSMHS019.bigfish.com (10.174.4.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Jun 2013 13:01:51 +0000 Received: from BL2PRD0610MB374.namprd06.prod.outlook.com ([169.254.5.235]) by BL2PRD0610HT003.namprd06.prod.outlook.com ([10.255.101.38]) with mapi id 14.16.0311.000; Fri, 7 Jun 2013 13:01:50 +0000 From: Dan York To: "dcrocker@bbiw.net" , Henning Schulzrinne Thread-Topic: [stir] Displaying a trust indicator (was: Re: A 4474 that will work through SBCs (generally/potentially)) Thread-Index: AQHOYzEFG/UxoMhC1k+ic5Cg64KobZkp9OgA Date: Fri, 7 Jun 2013 13:01:49 +0000 Message-ID: In-Reply-To: <51B15679.7060401@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1377DAFCF675034E80139798123844D0@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" Subject: Re: [stir] Displaying a trust indicator (was: Re: A 4474 that will work through SBCs (generally/potentially)) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 13:02:04 -0000 On 6/6/13 11:41 PM, "Dave Crocker" wrote: >On 6/7/2013 4:16 AM, Henning Schulzrinne wrote: >> I was thinking of the latter - add something to the textual display to >>indicate trust. > >The human factors design issues that the suggestion invokes >unfortunately are far more challenging and far less reliable than anyone >would wish. 100% agreed! >At the least, it's a topic that calls on UX/HCI expertise, rather than >protocol design expertise. They are very, very different domains of >knowledge. As a touchstone, I'll note that it's reasonable to assume >that it's good to always give more information, but the assumption is >wrong. Right. And as we've seen in the consumer space, it is often the simplest interfaces and user experiences that gain the widest adoption. Whether you like Apple or not, their "less is more" design focus has brought about mobile devices that are extremely easy to use and widely adopted - and that same design ethic is visible in many Android and other devices. Similarly, as a long-time user of Skype, I severely detested some of their recent UI changes that removed functionality and made the UI simpler... but I also found that a number of non-techie people I know really liked the newer simpler UI. >The dominant model in use for Internet anti-abuse work on adding >trust-related mechanisms is to target use by filtering engines by a >handling agent (possibly including the receiving user agent, but out of >sight of the actual user.) When we were have a similar debate back in 2008, I wrote a draft summarizing a number of the discussions we were having then: http://tools.ietf.org/html/draft-york-sip-visual-identifier-trusted-identit y-01 At that time, we didn't have all the many more devices that we do today... "smart" TVs, smart phones, and more. We were just thinking about softphones and "hard" IP phones. Over the 5 years since, though, I've come to question whether visual identifiers are really useful. I often see people who just click through web browser certificate warnings to get to their web page... and don't fully pay attention to whether they have a lock icon or whatever else the browser uses. When you have a visual identifier, you also then need to have another layer of security around that identifier to be sure that an attacker can't spoof the identifier on a particular device. I don=B9t know the answer... and I do agree with Dave that this particular question is one that probably merits assistance from people who are steeped in the UX/HCI world. Dan P.S. We've been having this same debate off and on within DNSSEC circles - should there be a visual identifier within, say, a web browser, when the browser is connecting to a site that has a DNSSEC-signed domain? Should there be warning messages? Or should it just fail to connect? What is the right balance? -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/=20 From md3135@att.com Fri Jun 7 08:21: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 4C55F21F91BC for ; Fri, 7 Jun 2013 08:21:54 -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=[AWL=0.001, 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 NwR+EBczTxJS for ; Fri, 7 Jun 2013 08:21:44 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEFE21F9050 for ; Fri, 7 Jun 2013 08:21:44 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 88af1b15.2aaad4813940.184627.00-573.519246.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 07 Jun 2013 15:21:44 +0000 (UTC) X-MXL-Hash: 51b1fa881f0c5e35-005df8f0af1dd66b0e1fc6e5dda25480020a6bcd Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 78af1b15.0.184619.00-487.519197.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 07 Jun 2013 15:21:43 +0000 (UTC) X-MXL-Hash: 51b1fa871a11d4be-14ac2ad0d5e515218eba0759ffce9b08d6f9c97c 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 r57FLgiU003124; Fri, 7 Jun 2013 11:21:42 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r57FLSdF002724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 11:21:32 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 7 Jun 2013 15:21:15 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 11:21:19 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne , Brian Rosen Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOYwNq0ALSXDZCyEmtgvtHhkZiE5kpQ/kNgABEIgCAAAvkAIAAFt+AgAAiVwCAAJHvAA== Date: Fri, 7 Jun 2013 15:21:18 +0000 Message-ID: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.92.146] 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=IZowrxWa c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=4XHnEduZkoUA:10 a=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oOBisLQmZ4cA:10 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8] X-AnalysisOut: [ a=HLLxP2VMAAAA:8 a=RMuq9hEgxJIuJuGmm-UA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=7DSvI1NPTFQA:10 a=-zy3ex45pM4A:10 a] X-AnalysisOut: [=BPp-Pk1G3X1gOtDr:21 a=-GEh_z0XBkSpp-hb:21] Cc: "stir@ietf.org" , Hadriel Kaplan , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 15:21:57 -0000 I do not believe we can add anything to ISUP -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, June 06, 2013 10:38 PM To: Brian Rosen Cc: Hadriel Kaplan; stir@ietf.org; DOLLY, MARTIN C; Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly My take is that the first SS7 carrier tends to be trusted (and trustworthy)= , and should be able to mark or drop bad-actor calls. (The former might inv= olve a new calling party category. Or you could use the prison phone catego= ry, anticipating future residential address of the caller.) On Jun 6, 2013, at 8:35 PM, Brian Rosen wrote: > The problem we're trying to solve has one end (the origination end) mostl= y on SIP and the termination end mostly on PSTN/2G/3G with, commonly, two o= r more transitions. >=20 > The origination end is mostly SIP because it's much much easier to manipu= late the signaling. The service providers that are tolerant of the problem= s are SIP service providers. They are mostly non-certificated carriers, wh= ich means they have to go through someone else to get to the termination ne= twork, because nearly all of the interconnects today are SS7. You often se= e 3 or more SIP providers, then an SS7 transition, then, increasingly, a co= nversion back to SIP, and finally the termination endpoint, which today is = heavily weighted POTS or 2G./3G wireless, but increasingly is SIP based. I= f the endpoint is enterprise, it's better. It's getting to all SIP on the = termination side quickly, but there is still an SS7 link between originatio= n and termination. >=20 > We can't deploy today, but if we try to deploy, say next year, then we ca= n't assume most carrier interconnect is SIP. Wish it were true, isn't. In= creasingly, there is a SIP leg in the termination side, and I think if we m= ake things work so we get that environment (SIP on origination, at least on= e SIP leg in termination, SS7 between origination and termination), we will= largely address the problems. It will get better as more legs migrate to = SIP, but if it has to be SIP end to end before the problem is addressed, wh= at we are attempting will be considered a fail. >=20 > If we make the mostly-but-not-all SIP scenario largely true, we will most= likely also help the case where there isn't (yet) a SIP leg on the termina= tion side, only because we will have enough disincentive in place so the pr= oblem sources will mostly be stymied. If at least one SIP leg only accepts= calls with a validated identity we can fix a lot of the problem. >=20 > So, there is a continuum: > If one leg on the origination side checks, we get the first real value, a= nd it's substantial > If one leg on the termination side checks, and we have SIP interconnect t= o that point, we have more value > If one leg on the termination side checks, and it works across an SS7 int= erconnect, we have a great deal of value > If we get end to end checks, we get to where we want to be eventually >=20 > The longer it takes to deploy, the more SIP interconnects there are and t= he value of a mechanism that works around the SS7 interconnect fades. We'r= e really trying to make a really significant dent in the problem well befor= e we expect that to happen, which is why I think having some mechanism to w= ork around an SS7 leg is going to be important. >=20 > But, there is no doubt that if we just get one leg in the origination sid= e to check, we get a big win. >=20 > Brian >=20 > On Jun 6, 2013, at 7:13 PM, Hadriel Kaplan wr= ote: >=20 >>=20 >> On Jun 6, 2013, at 6:31 PM, Brian Rosen wrote: >>=20 >>> Since virtually no bad calls are SIP end to end, it would seem that we = need something that lets us go SIP to PSTN to SIP, early on. >>=20 >> If virtually no bad calls are SIP the whole way, then identifying which = calls are SIP the whole way will tell you when the calls are good. ;) >>=20 >> (ie, using an authentication mechanism which works when calls are SIP th= e whole way might not be such a bad thing... it just won't tell you when le= gacy-PSTN-based calls are also good) >>=20 >> That's all we were really going to accomplish anyway - identify good cal= ler-ids, not identify bad ones. By that I mean it's not like there was goi= ng to be a flag day when suddenly everyone everywhere switches to doing som= e new caller-id mechanism; so instead we'd only be able to identify legitim= ate caller-ids for a portion of the calls, and the rest would basically be = "unverified" or whatever. So only the very "good guys" are going to be usi= ng this mechanism at first for a while anyway, and they generally use SIP a= lot already. >>=20 >> It might be reasonable to expect the adoption rate of a new caller-id au= th mechanism to follow the adoption rate of SIP interconnection, at least w= ithin the US/NANP (which is what started this topic). >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From hgs@cs.columbia.edu Fri Jun 7 08:36: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 1C19F21F96C6 for ; Fri, 7 Jun 2013 08:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E7yeiHHmTpZ for ; Fri, 7 Jun 2013 08:36:08 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3032021F965B for ; Fri, 7 Jun 2013 08:36:08 -0700 (PDT) Received: from [172.20.24.71] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r57Fa410002669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 11:36:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: Date: Fri, 7 Jun 2013 11:36:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "stir@ietf.org" , Richard Shockey , Hadriel Kaplan , Brian Rosen Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 15:36:14 -0000 I was thinking of a codepoint for CPC, not an addition to the protocol. On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" wrote: > I do not believe we can add anything to ISUP > From md3135@att.com Fri Jun 7 08:46: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 1338D21F9346 for ; Fri, 7 Jun 2013 08:46:46 -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 L+KLxltFl7G3 for ; Fri, 7 Jun 2013 08:46:39 -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 CBC3721F93B9 for ; Fri, 7 Jun 2013 08:46:38 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id e5002b15.2aaae602f940.214333.00-542.598362.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 07 Jun 2013 15:46:38 +0000 (UTC) X-MXL-Hash: 51b2005e3ce7047b-916d33075c5f00acefee22d64a29d09b55dc02de Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a5002b15.0.214328.00-472.598231.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 07 Jun 2013 15:46:34 +0000 (UTC) X-MXL-Hash: 51b2005a0ebbafbd-d1c9a2022255a2ff53b0a5ae615601b80f53ae4a 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 r57FkWFt002255; Fri, 7 Jun 2013 11:46:33 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r57FkI3W002104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 11:46:22 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 7 Jun 2013 15:46:07 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 11:46:11 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOYwNq0ALSXDZCyEmtgvtHhkZiE5kpQ/kNgABEIgCAAAvkAIAAFt+AgAAiVwCAAJHvAIAAR18A//+/UiA= Date: Fri, 7 Jun 2013 15:46:11 +0000 Message-ID: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> In-Reply-To: <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.92.146] 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=P+2NcF8u c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=4XHnEduZkoUA:10 a=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oOBisLQmZ4cA:10 a=48vgC7mUAAAA:8 a=W4-CMNVgA_7FLV] X-AnalysisOut: [IzH3AA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0c] X-AnalysisOut: [A:10] Cc: "stir@ietf.org" , Richard Shockey , Hadriel Kaplan , Brian Rosen Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 15:46:46 -0000 Henning, I chair the ATIS committee where the change would be made. I have an interi= m call on 6/17, and I can test the waters then. Regards, Martin -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Friday, June 07, 2013 11:36 AM To: DOLLY, MARTIN C Cc: Brian Rosen; Hadriel Kaplan; stir@ietf.org; Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly I was thinking of a codepoint for CPC, not an addition to the protocol. On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" wrote: > I do not believe we can add anything to ISUP >=20 From michael@voip.co.uk Fri Jun 7 09:20: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 746A921F973D for ; Fri, 7 Jun 2013 09:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4UV048KxKSYo for ; Fri, 7 Jun 2013 09:20:27 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with SMTP id 306A821F95DD for ; Fri, 7 Jun 2013 09:20:25 -0700 (PDT) Received: from mail-pb0-f47.google.com ([209.85.160.47]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUbIISbydet9uvSB69USlm4aZ197zS8vc@postini.com; Fri, 07 Jun 2013 09:20:26 PDT Received: by mail-pb0-f47.google.com with SMTP id rr13so2215836pbb.20 for ; Fri, 07 Jun 2013 09:20:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=25OY1karht6oyDi7r6N103EbC5YT/l2yXarssudUV8A=; b=DwwUmTbKpMOtUK9E2DOrPDm9bEuPEjmkEft82Gm6i/a2oM3Py5V/RXJYhH1H9kZRjS EYTYq8MAiKYyvaFSUeoUNwvbo4LdCtP0IHNwROwez4FkFZMBqctLU8/mim/MuPRqzhxz O7AC2N6rWWDW4zc/u4MACMYcLyfftnxeXBCDmHgLEVZ7+Kxp6F0P8dwNhzP+Kt3bmn09 6H1Wi5RKViEie2pYpcLyjFz7x6dMVhF+kejanuFDvZRdTHW5efElc43tocCUa/cyTs00 XZ0N4+s+UUauO9BG400P8Bw6hgWBH8nucbxkO29yi4RjMXKOwoIdhDaFPRPwoq1SPnIK 1TFQ== X-Received: by 10.68.245.170 with SMTP id xp10mr44605125pbc.41.1370622024264; Fri, 07 Jun 2013 09:20:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.245.170 with SMTP id xp10mr44605119pbc.41.1370622024175; Fri, 07 Jun 2013 09:20:24 -0700 (PDT) Received: by 10.70.118.71 with HTTP; Fri, 7 Jun 2013 09:20:24 -0700 (PDT) In-Reply-To: <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> References: <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> Date: Fri, 7 Jun 2013 17:20:24 +0100 Message-ID: From: Michael Procter To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=047d7b2e0c65df669f04de92ce20 X-Gm-Message-State: ALoCoQnmSDxyyOh7iMdntvMH7Dp421PwGKxYIcNGC98+0hmChVsjXhSSr8nC7AGvPEYVrNSc+Y57BwVsb5/ztAOT6p0vefMoi7IHRKUTyxja2z9EV2sGgaBMkj7kKWIyKUe6RZ0CliWm Cc: "stir@ietf.org" , Brian Rosen , Hadriel Kaplan , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 16:20:39 -0000 --047d7b2e0c65df669f04de92ce20 Content-Type: text/plain; charset=ISO-8859-1 On 7 June 2013 16:36, Henning Schulzrinne wrote: > I was thinking of a codepoint for CPC, not an addition to the protocol. > On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" wrote: >> I do not believe we can add anything to ISUP >> ISUP CLIs already come with a screening indicator. From memory, you can encode 4 meanings: - Network provided CLI - User Provided CLI - unscreened - User Provided CLI - verified and passed - User Provided CLI - verified and failed (often reserved for national use, if I recall correctly). When I last worked with ISUP (which was a while back), I think most networks essentially used only value. Whilst it sounds like this field would be a good match for the problem, you may find fewer interop concerns raised over introducing a new CPC value as you suggest. Regards, Michael --047d7b2e0c65df669f04de92ce20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7 June 2013 16:36, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
> I was thinking of a codepoint for CPC, not an addition= to the protocol.
>
On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" <md3135@att.com> wrote:
>> I do not believe we can add anything to ISUP
>>

ISUP CLIs already come with a screening indicator.=A0 From memory, yo= u can encode 4 meanings:
- Network provided CLI
- User Provided CLI -= unscreened
- User Provided CLI - verified and passed
- User Provided= CLI - verified and failed (often reserved for national use, if I recall co= rrectly).

When I last worked with ISUP (which was a while back), I think most net= works essentially used only value.=A0 Whilst it sounds like this field woul= d be a good match for the problem, you may find fewer interop concerns rais= ed over introducing a new CPC value as you suggest.

Regards,

Michael
--047d7b2e0c65df669f04de92ce20-- From md3135@att.com Fri Jun 7 09:30: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 6BF3721F93F8 for ; Fri, 7 Jun 2013 09:30:12 -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=[AWL=-0.000, 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 aaPgJ0dEky0p for ; Fri, 7 Jun 2013 09:30:03 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 050A221F925A for ; Fri, 7 Jun 2013 09:30:02 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a8a02b15.51185940.228204.00-514.644075.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 07 Jun 2013 16:30:02 +0000 (UTC) X-MXL-Hash: 51b20a8a5414786b-e7cf8ddb46bb19d892a8fdcf1ec8729d8b7cb5f2 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 98a02b15.0.228190.00-163.644020.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 07 Jun 2013 16:30:02 +0000 (UTC) X-MXL-Hash: 51b20a8a72e77c9e-ed7d6388a4b76364fb57179828803f64e5c7c60a 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 r57GU02a019967; Fri, 7 Jun 2013 12:30:01 -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 r57GTms5019839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 12:29:51 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 7 Jun 2013 16:29:32 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 12:29:36 -0400 From: "DOLLY, MARTIN C" To: Michael Procter , Henning Schulzrinne Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially Thread-Index: AQHOY5rp0ALSXDZCyEmtgvtHhkZiE5kqbwZg Date: Fri, 7 Jun 2013 16:29:36 +0000 Message-ID: References: <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.92.146] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560215D1E9MISOUT7MSGUSR9I_" 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=IZowrxWa c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=4XHnEduZkoUA:10 a=mlEcyjPe5jgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=oOBisLQmZ] X-AnalysisOut: [4cA:10 a=g3oejx0OAAAA:8 a=48vgC7mUAAAA:8 a=DGMDLixjIMPKVRL] X-AnalysisOut: [DZpoA:9 a=CjuIK1q_8ugA:10 a=4RuB4YTyq4IA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [Ddgi3LTtw5Rwko0ZqboA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10] X-AnalysisOut: [ a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=4] X-AnalysisOut: [SHKWkmzPzxc0K5s:21] Cc: "stir@ietf.org" , Brian Rosen , Hadriel Kaplan , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 16:30:12 -0000 --_000_E42CCDDA6722744CB241677169E836560215D1E9MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These values are implemented as of 4E14 & 5E6 From: Michael Procter [mailto:michael@voip.co.uk] Sent: Friday, June 07, 2013 12:20 PM To: Henning Schulzrinne Cc: DOLLY, MARTIN C; stir@ietf.org; Richard Shockey; Hadriel Kaplan; Brian = Rosen Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly On 7 June 2013 16:36, Henning Schulzrinne > wrote: > I was thinking of a codepoint for CPC, not an addition to the protocol. > On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" > wrote: >> I do not believe we can add anything to ISUP >> ISUP CLIs already come with a screening indicator. From memory, you can en= code 4 meanings: - Network provided CLI - User Provided CLI - unscreened - User Provided CLI - verified and passed - User Provided CLI - verified and failed (often reserved for national use,= if I recall correctly). When I last worked with ISUP (which was a while back), I think most network= s essentially used only value. Whilst it sounds like this field would be a= good match for the problem, you may find fewer interop concerns raised ove= r introducing a new CPC value as you suggest. Regards, Michael --_000_E42CCDDA6722744CB241677169E836560215D1E9MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These values are implemented as of  4E14 & = 5E6

 <= /p>

From: Michael = Procter [mailto:michael@voip.co.uk]
Sent: Friday, June 07, 2013 12:20 PM
To: Henning Schulzrinne
Cc: DOLLY, MARTIN C; stir@ietf.org; Richard Shockey; Hadriel Kaplan;= Brian Rosen
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially

 

On 7 June 2013 16:36, Henning Schulzrinne <hgs@cs.columbia.edu&= gt; wrote:
> I was thinking of a codepoint for CPC, not an addition to the protocol= .
>

On Jun 7, 2013, at 11= :21 AM, "DOLLY, MARTIN C" <m= d3135@att.com> wrote:
>> I do not believe we can add anything to ISUP
>>

ISUP CLIs already come with a screening indicator.&n= bsp; From memory, you can encode 4 meanings:
- Network provided CLI
- User Provided CLI - unscreened
- User Provided CLI - verified and passed
- User Provided CLI - verified and failed (often reserved for national use,= if I recall correctly).

When I last worked with ISUP (which was a while back), I think most network= s essentially used only value.  Whilst it sounds like this field would= be a good match for the problem, you may find fewer interop concerns raise= d over introducing a new CPC value as you suggest.

Regards,

Michael

--_000_E42CCDDA6722744CB241677169E836560215D1E9MISOUT7MSGUSR9I_-- From hadriel.kaplan@oracle.com Fri Jun 7 09:50: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 0D0AE21F9925 for ; Fri, 7 Jun 2013 09:50:39 -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=[AWL=-0.000, BAYES_00=-2.599, 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 ci+FKdP2l1No for ; Fri, 7 Jun 2013 09:50:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8121F8613 for ; Fri, 7 Jun 2013 09:50:23 -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 r57GoIUU016948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 16:50:19 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 r57GoGEq013618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 16:50:17 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57GoGY4000347; Fri, 7 Jun 2013 16:50:16 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 09:50:15 -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: <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> Date: Fri, 7 Jun 2013 12:50:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41EB8BF0-5F36-43F5-A8CC-3D884258398C@oracle.com> References: > <> <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 16:50:39 -0000 On Jun 6, 2013, at 8:35 PM, Brian Rosen wrote: > The problem we're trying to solve has one end (the origination end) = mostly on SIP and the termination end mostly on PSTN/2G/3G with, = commonly, two or more transitions. > The origination end is mostly SIP because it's much much easier to = manipulate the signaling. The service providers that are tolerant of = the problems are SIP service providers. They are mostly = non-certificated carriers, which means they have to go through someone = else to get to the termination network, because nearly all of the = interconnects today are SS7. You often see 3 or more SIP providers, = then an SS7 transition, then, increasingly, a conversion back to SIP, = and finally the termination endpoint, which today is heavily weighted = POTS or 2G./3G wireless, but increasingly is SIP based. If the endpoint = is enterprise, it's better. It's getting to all SIP on the termination = side quickly, but there is still an SS7 link between origination and = termination. Yes, the origination and termination is SIP - even though 2G/3G the = handset itself isn't SIP, but there's SIP in the termination carrier up = to the MSC/CPE/ATA. And for cases where the termination provider isn't = SIP, there's absolutely nothing we can do for them, because no one's = investing in new SS7 functions. Regardless, the point I was trying to make in my previous email is the = bad guys, or even the "pink carriers", aren't the ones we have to = worry-about/handle supporting this mechanism, because by definition = they're not going to use it. Whether they go through SS7 or carrier = pigeon doesn't matter. All we can do is identify the good caller-ids = from the good guys. So my point was the good guys are using SIP more = and more, including for interconnection. =20 If we can get sufficient use/coverage such that unsigned national number = caller-id's due to SS7 become marked as "unknown" or "unverified", then = that incites the rest to go SIP. > We can't deploy today, but if we try to deploy, say next year, then we = can't assume most carrier interconnect is SIP. Wish it were true, = isn't. Increasingly, there is a SIP leg in the termination side, and I = think if we make things work so we get that environment (SIP on = origination, at least one SIP leg in termination, SS7 between = origination and termination), we will largely address the problems. It = will get better as more legs migrate to SIP, but if it has to be SIP end = to end before the problem is addressed, what we are attempting will be = considered a fail. OK, if you want to be realistic, here is realism: the IETF RAI area has = never gone from BOF to published RFC in a year, afaik. Martini was just = slightly longer than a year. So let's assume the best-case: it takes = one year to publish this new caller-id thing. Most of the big vendors = won't start implementing anything until there's a published RFC. Let's = assume it takes them 6 months to get it into a GA release (it usually = takes more). Then the service providers have to start testing the new = release, another 6 months. Now we're at two years. Then assuming it all = works well they schedule deployment for some 3-6 months after that. = That's all assuming you hit the timing right for each phase's window, = which never happens. Realistically, we're talking 3 to 4 years from now = for the big carriers. And that's probably being aggressive. -hadriel From br@brianrosen.net Fri Jun 7 09:58: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 227AB21F92E3 for ; Fri, 7 Jun 2013 09:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 tSbsQatySVdv for ; Fri, 7 Jun 2013 09:58:26 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2BE21F9079 for ; Fri, 7 Jun 2013 09:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=TXYskjbaoordYD2xfbZNayEdEp4mqI8crlYzBaA5yU4=; b=EwiMRCdY2PrXu/AQW99v853AGzGYspA/1VPg95lQ4Q9JY8pzRfLYm31MawaSMGb7T5ibGtjYF8Q1AsMmRN43jhDY2e4UUChsPDLDZ5kVKNN8KpB1YVx7Vq+e44UjmRE74+O4N3eVQxJ4Y7hzfGcrXL777hmLs2j6wu6umNGx3f8=; Received: from neustargw.va.neustar.com ([209.173.53.233]:35355 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ukzzd-0006xH-7P; Fri, 07 Jun 2013 12:58:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <41EB8BF0-5F36-43F5-A8CC-3D884258398C@oracle.com> Date: Fri, 7 Jun 2013 12:58:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BD245FC-730F-4A18-B627-BE4E839E27BF@brianrosen.net> References: > <> <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <41EB8BF0-5F36-43F5-A8CC-3D884258398C@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 16:58:38 -0000 I can be optimistic, can't I? Suppose it was 3-4 years. I really doubt that we will have more than = 50% SIP end to end (let's say originating SP to terminating SP) by then. It's pretty clear that we all agree that the basic sign and check = feature is the first thing we need to do. =20 What we're discussing is whether a mechanism that helps get through non = cooperating intermediaries is worth doing. I think it is, especially if we can figure out how to make it relatively = easy to deploy. I will agree with you that if such mechanisms are delayed, or hard to = deploy, that the value decreases. Brian On Jun 7, 2013, at 12:50 PM, Hadriel Kaplan = wrote: >=20 > On Jun 6, 2013, at 8:35 PM, Brian Rosen wrote: >=20 >> The problem we're trying to solve has one end (the origination end) = mostly on SIP and the termination end mostly on PSTN/2G/3G with, = commonly, two or more transitions. >> The origination end is mostly SIP because it's much much easier to = manipulate the signaling. The service providers that are tolerant of = the problems are SIP service providers. They are mostly = non-certificated carriers, which means they have to go through someone = else to get to the termination network, because nearly all of the = interconnects today are SS7. You often see 3 or more SIP providers, = then an SS7 transition, then, increasingly, a conversion back to SIP, = and finally the termination endpoint, which today is heavily weighted = POTS or 2G./3G wireless, but increasingly is SIP based. If the endpoint = is enterprise, it's better. It's getting to all SIP on the termination = side quickly, but there is still an SS7 link between origination and = termination. >=20 > Yes, the origination and termination is SIP - even though 2G/3G the = handset itself isn't SIP, but there's SIP in the termination carrier up = to the MSC/CPE/ATA. And for cases where the termination provider isn't = SIP, there's absolutely nothing we can do for them, because no one's = investing in new SS7 functions. >=20 > Regardless, the point I was trying to make in my previous email is the = bad guys, or even the "pink carriers", aren't the ones we have to = worry-about/handle supporting this mechanism, because by definition = they're not going to use it. Whether they go through SS7 or carrier = pigeon doesn't matter. All we can do is identify the good caller-ids = from the good guys. So my point was the good guys are using SIP more = and more, including for interconnection. =20 >=20 > If we can get sufficient use/coverage such that unsigned national = number caller-id's due to SS7 become marked as "unknown" or = "unverified", then that incites the rest to go SIP. >=20 >=20 >> We can't deploy today, but if we try to deploy, say next year, then = we can't assume most carrier interconnect is SIP. Wish it were true, = isn't. Increasingly, there is a SIP leg in the termination side, and I = think if we make things work so we get that environment (SIP on = origination, at least one SIP leg in termination, SS7 between = origination and termination), we will largely address the problems. It = will get better as more legs migrate to SIP, but if it has to be SIP end = to end before the problem is addressed, what we are attempting will be = considered a fail. >=20 > OK, if you want to be realistic, here is realism: the IETF RAI area = has never gone from BOF to published RFC in a year, afaik. Martini was = just slightly longer than a year. So let's assume the best-case: it = takes one year to publish this new caller-id thing. Most of the big = vendors won't start implementing anything until there's a published RFC. = Let's assume it takes them 6 months to get it into a GA release (it = usually takes more). Then the service providers have to start testing = the new release, another 6 months. Now we're at two years. Then = assuming it all works well they schedule deployment for some 3-6 months = after that. That's all assuming you hit the timing right for each = phase's window, which never happens. Realistically, we're talking 3 to = 4 years from now for the big carriers. And that's probably being = aggressive. >=20 > -hadriel >=20 From hadriel.kaplan@oracle.com Fri Jun 7 10:03: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 3913E21F93D2 for ; Fri, 7 Jun 2013 10:03:33 -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=[AWL=-0.000, BAYES_00=-2.599, 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 Wwk7sWNjBL5C for ; Fri, 7 Jun 2013 10:03:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0460421F95EF for ; Fri, 7 Jun 2013 10:03:23 -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 r57H2rFp007087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 17:02:54 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 r57H2sGO017656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 17:02:54 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 r57H2sdq012590; Fri, 7 Jun 2013 17:02:54 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 10:02: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: <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> Date: Fri, 7 Jun 2013 13:02:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Brian Rosen , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:03:33 -0000 I'm not sure I understand the logic here. Why would we trust a "not-evil" bit coming in from SS7/ISUP? Why wouldn't all pink carriers just start setting that bit? At some point you said we can trust the SS7 carrier, but really we can't = - or rather, it's too late by then. The pink carriers egress their = calls on PRIs/etc. on gateways they own. The next transit carrier has = no idea if the transmitted CgPN is valid or not. Did I miss something? -hadriel On Jun 7, 2013, at 11:36 AM, Henning Schulzrinne = wrote: > I was thinking of a codepoint for CPC, not an addition to the = protocol. >=20 > On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" wrote: >=20 >> I do not believe we can add anything to ISUP >>=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Fri Jun 7 10:10: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 AA78D21F96DF for ; Fri, 7 Jun 2013 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 kzMUUZOMtVwD for ; Fri, 7 Jun 2013 10:10:23 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3883B21F96A9 for ; Fri, 7 Jun 2013 10:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=pWfB5TjiPMVmzvXnFqTWmBBcY3qSvmMLLLGEyoYObEE=; b=cNCeMuN2A7fO1maYpEs7yxnkYlcVsdLhO3pozaZDtpZFFQpE7l+62IvXzqj/pMrvvfRJvb7Nz/RSqJkenzBjE0UiA9klxN83xYOls3Ohpid9g8le7JrzkxC8lwnpkxnjitKgi+1rY2JFdykC/ffMaTfQBEcelHsnp/epyeKM6hs=; Received: from neustargw.va.neustar.com ([209.173.53.233]:30141 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ul0BB-0001q6-1f; Fri, 07 Jun 2013 13:10:21 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: Date: Fri, 7 Jun 2013 13:10:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1919B30B-BA7E-4E48-A273-DED4720B6298@brianrosen.net> References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Richard Shockey , "DOLLY, MARTIN C" , Henning Schulzrinne Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:10:27 -0000 Turns out that the "pink carriers" don't own the PSTN interconnects by = and large. They are SIP only. They pass calls to a certificated = carrier who is actually pretty trustworthily mostly. That isn't always = true, but it's mostly true. I'm still not sure we can get those carriers to implement a validity = check and cause the SS7 gateways to set the not-evil bit, but it may be = possible. The out of band DB still seems to be a better solution but this could = help. Brian On Jun 7, 2013, at 1:02 PM, Hadriel Kaplan = wrote: >=20 > I'm not sure I understand the logic here. > Why would we trust a "not-evil" bit coming in from SS7/ISUP? > Why wouldn't all pink carriers just start setting that bit? >=20 > At some point you said we can trust the SS7 carrier, but really we = can't - or rather, it's too late by then. The pink carriers egress = their calls on PRIs/etc. on gateways they own. The next transit carrier = has no idea if the transmitted CgPN is valid or not. > Did I miss something? >=20 > -hadriel >=20 >=20 > On Jun 7, 2013, at 11:36 AM, Henning Schulzrinne = wrote: >=20 >> I was thinking of a codepoint for CPC, not an addition to the = protocol. >>=20 >> On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" = wrote: >>=20 >>> I do not believe we can add anything to ISUP >>>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From brian.rosen@neustar.biz Fri Jun 7 10:20: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 EBCE621F994D for ; Fri, 7 Jun 2013 10:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5JAL5K36njN3 for ; Fri, 7 Jun 2013 10:20:31 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A121F8EC3 for ; Fri, 7 Jun 2013 10:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370625810; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=DNba1ObznpSIyH2WOOL66mf+rqeLXP+9/7JMzEcuxsE=; b=hRKVgo19anU7nAcsZ3k56L563a9cmDstC5NQMEXgHKLXXQht8Js+8GkViYoLQ5 o8b5KNT+BIrQpek2A4dc/hUw== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24777887; Fri, 07 Jun 2013 13:23:28 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 13:20:26 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 13:20:25 -0400 From: "Rosen, Brian" To: "stir@ietf.org" Thread-Topic: Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlg== Date: Fri, 7 Jun 2013 17:20:24 +0000 Message-ID: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: sfTYloxh84kVl1fuu5uqtQ== Content-Type: multipart/alternative; boundary="_000_9CC39DA786104284B51E5FA7E2A59C0Fneustarbiz_" MIME-Version: 1.0 Subject: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:20:36 -0000 --_000_9CC39DA786104284B51E5FA7E2A59C0Fneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The fundamental idea that we have here is that you sign a set of informatio= n with a credential, and you pass the signature and a pointer to the creden= tial in SIP signaling. We have some disagreements about what is signed. Henning has proposed that we canonicalize the From and To phone numbers, we= include a timestamp and some form of call-id, possibly the INSIPID id. There are assertions that you can't use From/To, because middle boxes chang= e them. Some have suggested using P-A-I and other headers instead. Hadriel wrote a draft about why From and To get modified: http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt After reading it, I am unclear if a canonicalized e.164 would make it throu= gh. The reasons given seem to indicate they would. They change domains, t= hey change prefixes, but they don't seem to change the actual telephone num= ber. Can we come up with examples where a canonicalized e.164 would NOT pass end= to end? Brian --_000_9CC39DA786104284B51E5FA7E2A59C0Fneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <237331B9AB15364681B512E20223971B@neustar.biz> Content-Transfer-Encoding: quoted-printable The fundamental idea that we have here is that you sign a set of informatio= n with a credential, and you pass the signature and a pointer to the creden= tial in SIP signaling.

We have some disagreements about what is signed.

Henning has proposed that we canonicalize the From and To phone number= s, we include a timestamp and some form of call-id, possibly the INSIPID id= .  

There are assertions that you can't use From/To, because middle boxes = change them.  Some have suggested using P-A-I and other headers instea= d.

Hadriel wrote a draft about why From and To get modified:

After reading it, I am unclear if a canonicalized e.164 would make it = through.  The reasons given seem to indicate they would.  They ch= ange domains, they change prefixes, but they don't seem to change the actua= l telephone number.

Can we come up with examples where a canonicalized e.164 would NOT pas= s end to end?

Brian
--_000_9CC39DA786104284B51E5FA7E2A59C0Fneustarbiz_-- From hadriel.kaplan@oracle.com Fri Jun 7 10:34: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 809B821F8FEB for ; Fri, 7 Jun 2013 10:34:05 -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=[AWL=-0.000, BAYES_00=-2.599, 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 KUHWpFn6jVZh for ; Fri, 7 Jun 2013 10:33:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D6BD621F8FCB for ; Fri, 7 Jun 2013 10:33:53 -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 r57HXfsf011279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 17:33:41 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 r57HXg7G002350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 17:33:42 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 r57HXfVa005516; Fri, 7 Jun 2013 17:33:41 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 10:33: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: <1919B30B-BA7E-4E48-A273-DED4720B6298@brianrosen.net> Date: Fri, 7 Jun 2013 13:33:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> <1919B30B-BA7E-4E48-A273-DED4720B6298@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , Henning Schulzrinne , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:34:05 -0000 Hmmm... maybe I'm using a different definition for "pink carrier". I = was thinking a pink carrier was an origination or transit provider that = doesn't care whether it's caller-id's are bogus or not. Not because = it's malicious or setting invalid caller-ids itself, but just because it = receives it that way form its customers and doesn't know better or = doesn't care so long as it gets paid. I know some carriers like that, = and they have PSTN gateways upstream. As far as I know they're not "SS7 = carriers" in that they don't have STPs and point codes - but they have = SIP-PRI gateways, and their PRIs go to SS7 carriers. Are you saying that those are the pink carriers, but that usually = they've got SIP upstream to their next transit carrier; or are you = saying those are the green carriers and the pink carriers are their = customers, the ones setting bogus caller-ids on purpose? -hadriel On Jun 7, 2013, at 1:10 PM, Brian Rosen wrote: > Turns out that the "pink carriers" don't own the PSTN interconnects by = and large. They are SIP only. They pass calls to a certificated = carrier who is actually pretty trustworthily mostly. That isn't always = true, but it's mostly true. >=20 > I'm still not sure we can get those carriers to implement a validity = check and cause the SS7 gateways to set the not-evil bit, but it may be = possible. >=20 > The out of band DB still seems to be a better solution but this could = help. >=20 > Brian >=20 > On Jun 7, 2013, at 1:02 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> I'm not sure I understand the logic here. >> Why would we trust a "not-evil" bit coming in from SS7/ISUP? >> Why wouldn't all pink carriers just start setting that bit? >>=20 >> At some point you said we can trust the SS7 carrier, but really we = can't - or rather, it's too late by then. The pink carriers egress = their calls on PRIs/etc. on gateways they own. The next transit carrier = has no idea if the transmitted CgPN is valid or not. >> Did I miss something? >>=20 >> -hadriel >>=20 >>=20 >> On Jun 7, 2013, at 11:36 AM, Henning Schulzrinne = wrote: >>=20 >>> I was thinking of a codepoint for CPC, not an addition to the = protocol. >>>=20 >>> On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" = wrote: >>>=20 >>>> I do not believe we can add anything to ISUP >>>>=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 br@brianrosen.net Fri Jun 7 10:50: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 2921B21F997E for ; Fri, 7 Jun 2013 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.279 X-Spam-Level: X-Spam-Status: No, score=-100.279 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, 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 BleT+o4lgDCs for ; Fri, 7 Jun 2013 10:50:13 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id E5F2821F996D for ; Fri, 7 Jun 2013 10:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=iqxNql6kV3UbZBW/gY8H8fsuevMwjGgZwNtmBmklk1Q=; b=bYRI2A9GspipsZXs2jo6frBMaK4wQgcVkbgUWQ+vUFCUU6klHBt1Hm2w8J8yBsHbDreYGBlUhStsbBs2Od5Ax+1e9c8h3Rwgyw3rw3UfL9ZgtA+U6TBEs2QjVtrQPLnbEG+LdHYMdBJVuxKwpKHVmbNpD6EKikxVdomPVKMI07I=; Received: from neustargw.va.neustar.com ([209.173.53.233]:29082 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Ul0nV-0000cE-Rx; Fri, 07 Jun 2013 13:49:57 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: Date: Fri, 7 Jun 2013 13:49:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> <1919B30B-BA7E-4E48-A273-DED4720B6298@brianrosen.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Henning Schulzrinne , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:50:18 -0000 Henning can tell us more, but I understand that at least in the U.S., = most of the bad calls are coming from carriers that are not = certificated, and are SIP connected to a certificated carrier. They = purchase numbers from that carrier. They are SIP only. Many of the certificated carriers currently do not check the validity of = the calling party number for calls arriving on their wholesale side via = SIP. It's pretty difficult - the upstream service provider could have = millions of numbers spread across all the rate centers the certificated = carrier has service in. Martin can speak to whether AT&T tries to do = that. I certainly do worry about a pink carrier with an SS7 connection. There = are some certificated carriers that provide such services and if we = close off the SIP interconnect path, they may seek out the SS7 path. = That would be bad because then we have no green carrier before we get to = SS7. It may be that we can work out ways to encourage such carriers to = migrate their customers to SIP trunks rather than PRI and then be in a = place to fix the issues. Brian On Jun 7, 2013, at 1:33 PM, Hadriel Kaplan = wrote: >=20 > Hmmm... maybe I'm using a different definition for "pink carrier". I = was thinking a pink carrier was an origination or transit provider that = doesn't care whether it's caller-id's are bogus or not. Not because = it's malicious or setting invalid caller-ids itself, but just because it = receives it that way form its customers and doesn't know better or = doesn't care so long as it gets paid. I know some carriers like that, = and they have PSTN gateways upstream. As far as I know they're not "SS7 = carriers" in that they don't have STPs and point codes - but they have = SIP-PRI gateways, and their PRIs go to SS7 carriers. >=20 > Are you saying that those are the pink carriers, but that usually = they've got SIP upstream to their next transit carrier; or are you = saying those are the green carriers and the pink carriers are their = customers, the ones setting bogus caller-ids on purpose? >=20 > -hadriel >=20 >=20 > On Jun 7, 2013, at 1:10 PM, Brian Rosen wrote: >=20 >> Turns out that the "pink carriers" don't own the PSTN interconnects = by and large. They are SIP only. They pass calls to a certificated = carrier who is actually pretty trustworthily mostly. That isn't always = true, but it's mostly true. >>=20 >> I'm still not sure we can get those carriers to implement a validity = check and cause the SS7 gateways to set the not-evil bit, but it may be = possible. >>=20 >> The out of band DB still seems to be a better solution but this could = help. >>=20 >> Brian >>=20 >> On Jun 7, 2013, at 1:02 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> I'm not sure I understand the logic here. >>> Why would we trust a "not-evil" bit coming in from SS7/ISUP? >>> Why wouldn't all pink carriers just start setting that bit? >>>=20 >>> At some point you said we can trust the SS7 carrier, but really we = can't - or rather, it's too late by then. The pink carriers egress = their calls on PRIs/etc. on gateways they own. The next transit carrier = has no idea if the transmitted CgPN is valid or not. >>> Did I miss something? >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Jun 7, 2013, at 11:36 AM, Henning Schulzrinne = wrote: >>>=20 >>>> I was thinking of a codepoint for CPC, not an addition to the = protocol. >>>>=20 >>>> On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" = wrote: >>>>=20 >>>>> I do not believe we can add anything to ISUP >>>>>=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 >=20 From bernard.aboba@gmail.com Fri Jun 7 10:58: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 B628C21F9991 for ; Fri, 7 Jun 2013 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 eeGgo4rLdzdA for ; Fri, 7 Jun 2013 10:58:01 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2590621F96E9 for ; Fri, 7 Jun 2013 10:57:54 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so1074294qae.13 for ; Fri, 07 Jun 2013 10:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OGpWIi5csEpQz4XhBL7ohHRdJ0bjuUdlVcChu0u+tjg=; b=cZW4p4LLcN3n4kSp2i0g7eQ4OjQfgnJEoTna0/t85oTcfKv1uI1reMlUc1iYJEigfb C3HFUohrqdRbCty4JIx0PhJzqCA14cce/FGWJK9/Rui+Erprrg/xiY3SdO2vPxjYv948 MHx351dscymPnEZNO2dqbdPgq6dqFzJUucOqWv+A3mk4FqaPEYT29Wo1AZJT8Bb2FCVo x/dYfDeSOdTnnUg+hBHFMR4HT96LUkJikkBC+APsWVwBClrEAX+R7zjxSRqJ6J7EH7Au Fq0+lx1HACcl171jw5KNu2XPUASd8ze5nH2w54YHtes3N1EzDSOOKmJMLg9y+dAC/lVf ba3Q== X-Received: by 10.49.62.72 with SMTP id w8mr48689434qer.22.1370627873520; Fri, 07 Jun 2013 10:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.74.34 with HTTP; Fri, 7 Jun 2013 10:57:33 -0700 (PDT) In-Reply-To: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> From: Bernard Aboba Date: Fri, 7 Jun 2013 10:57:33 -0700 Message-ID: To: "Rosen, Brian" Content-Type: text/plain; charset=ISO-8859-1 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 17:58:02 -0000 On Fri, Jun 7, 2013 at 10:20 AM, Rosen, Brian wrote: > There are assertions that you can't use From/To, because middle boxes change > them. Some have suggested using P-A-I and other headers instead. > > Can we come up with examples where a canonicalized e.164 would NOT pass end to end? [ BA] Some PBXes appear to change the From: and To: headers when implementing find-me-followme. Of course there are alternatives (e.g. change only the Request-URI and use History-Info). From brian.rosen@neustar.biz Fri Jun 7 11:08: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 56D4321F9600 for ; Fri, 7 Jun 2013 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 te0GOXvRzItB for ; Fri, 7 Jun 2013 11:08:12 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C10A821F8F6E for ; Fri, 7 Jun 2013 11:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370628671; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=4AL0BJjtvT qx8BExzXe0z7EV4CIpF7dE2F1xdUPB1uc=; b=HTmahrB1Gn3VxPDaX9qsZkz9fe DO4VnqiIKmwGuCSH1AYCjavjxjvfBrFGruOyTZYy9329ksQlkm3MK6SvbbRg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24780969; Fri, 07 Jun 2013 14:11:10 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:08:08 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:08:05 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkqzRkAgAAClAA= Date: Fri, 7 Jun 2013 18:08:04 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> In-Reply-To: <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tkDBvtIl/FTtQ3rs+9KSvA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:08:18 -0000 Yes, I'm asking if we can avoid using alternative headers. I'll start a thread on call forward/follow-me. I think presence of most prefixes would be pretty easy to deal with. I wou= ld not expect to see the PBX prefixes (9-1-202-555-1212), because the downs= tream entities couldn't route if they were there. Can anyone else on the list find examples where prefixes may confuse a cano= nicalization routine on From/To? Brian On Jun 7, 2013, at 1:58 PM, Hadriel Kaplan wrote: >=20 > On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" wrot= e: >=20 >> After reading it, I am unclear if a canonicalized e.164 would make it th= rough. The reasons given seem to indicate they would. They change domains= , they change prefixes, but they don't seem to change the actual telephone = number. >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >=20 > Depends on how you mean this - do you mean can we avoid putting a canonic= al version into a separate header, and instead keep it in the From/To? > I don't know that we can really know the answer to that universally. >=20 > There are some times when the From/To username numbers are changed for re= asons other than what I had in that old draft. For example sometimes they'= re pre-pended with prefixes used for routing purposes, but the prefix is la= ter removed before egressing the network. That probably wouldn't matter so= long as it got inserted after the signer and removed before the verifier, = or the signer/verifier were aware of it. Also the From number is sometimes= replaced with a general company number, to hide the specific agent/attenda= nt making a call; but that would hopefully happen before signing so it won'= t matter. Sometimes the To is changed due to call forwarding/hunting/selec= tion to be the new destination number, despite the RFCs that say otherwise. >=20 > -hadriel >=20 From brian.rosen@neustar.biz Fri Jun 7 11:18: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 D6F1321F9986 for ; Fri, 7 Jun 2013 11:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 9ZJIPiXGWQVE for ; Fri, 7 Jun 2013 11:18:06 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6483721F9977 for ; Fri, 7 Jun 2013 11:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370629264; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=UKF0q2cVEO KFp+/z6pSH5OpToEFvhPXQOm4pBjihQVY=; b=NLdKh1Ik3KworvtWG3GlCCyQ6r 1ZhMLcJ5KT3A/tGdmMmJn5yC0NyutvSVcM/RfSNzNDGLd6BRkIzf6f67Ruqg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24781497; Fri, 07 Jun 2013 14:21:03 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:18:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:17:58 -0400 From: "Rosen, Brian" To: "stir@ietf.org" Thread-Topic: Call Forward/Follow-me Thread-Index: AQHOY6tWGjfCXtwTp0y4gL5mXFSX9A== Date: Fri, 7 Jun 2013 18:17:57 +0000 Message-ID: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hY3rjWjF8ZCiNaniJIOnXA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [stir] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:18:11 -0000 A problem that has been noted is PBXs and other services that implement Cal= l Forward and Follow-me by spoofing From to be the original caller when the= y originate a call from the PBX to the ultimate destination. They do this = so that the called party sees the original caller when they get the call. If we outlaw spoofing, these services wouldn't be able to do that. They wo= uld have to use History or other headers to pass the original calling party= number. I believe that we can't continue to allow this kind of spoofing. There are= other headers which are appropriate for use. One of the arguments given is that in older systems such as POTS or 2G/3G, = there is no way to get caller ID to show data from the other headers. I th= ink we have to accept such limitations. Newer systems would not have that = problem of course. While it may be unfortunate that something like forward or follow-me doesn'= t work as well as it did, I think that it's the right tradeoff. Please note that there are another class of calling party number spoofing c= ircumstances we CAN do something about. Suppose a doctor wants to place a = call on her mobile that appears to come from her office number. In that ca= se the doctor can authorize the service that arranges that call. They can = get the cert for the office number and authorize the service to place calls= with that number by giving them a cert for that authorization. This also = works for, as an example, a call center placing calls for an enterprise. The difference is, of course, that the "spoofed" number is a number delegat= ed to the entity spoofing, rather than the forward/follow me case where the= spoofed number is the calling party and the entity spoofing is authorized = by the called party. Brian= From alan.b.johnston@gmail.com Fri Jun 7 11: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 6280421F9712 for ; Fri, 7 Jun 2013 11:23:19 -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, HTML_MESSAGE=0.001, 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 gn0FelqJYuye for ; Fri, 7 Jun 2013 11:23:18 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9351E21F96E4 for ; Fri, 7 Jun 2013 11:23:17 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so1578168wgh.1 for ; Fri, 07 Jun 2013 11:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BmtcY60mPngjDXcp0wN1Id9u1kHRVk7QVSQr9KW2gWc=; b=lPCitb9UOq7P4vmhLWuZ7kQbUJU/jxcKB67tP7lXkJIHlblNy3c0NVuhNmTtZO7Erp 8YhEVyxUmgxnElx7TYmEhtv6DfbiOezuiAeMgKbDME2+hM7rGG82usfMpKMwNLakwElk GWWpizHzxacJEGh+gIdGFVmnhxgYSUBaLTy5iT33rLLogQSzhiNXfZ/R/IJviPdsym8D hdDWNkX0+S0l7+nSfoPAz0OtN3/DVVUinUxHyhAj9Xxz+bJRVTOBkzSjOJV/ZYbzUdlm wvARxcsvwg0WF+f8EF0hhTEg3YU97UPOFaIZhZtQjqj9Nwu/MolrK9raniGgX3kc9qZB cPiw== MIME-Version: 1.0 X-Received: by 10.181.11.194 with SMTP id ek2mr2189829wid.27.1370629396707; Fri, 07 Jun 2013 11:23:16 -0700 (PDT) Received: by 10.216.83.205 with HTTP; Fri, 7 Jun 2013 11:23:16 -0700 (PDT) In-Reply-To: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> Date: Fri, 7 Jun 2013 13:23:16 -0500 Message-ID: From: Alan Johnston To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=f46d043bdee44f3ffa04de948615 Cc: "stir@ietf.org" Subject: Re: [stir] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:23:20 -0000 --f46d043bdee44f3ffa04de948615 Content-Type: text/plain; charset=ISO-8859-1 I think that History-Info should be the solution going forward, certainly for SIP networks. - Alan - On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian wrote: > A problem that has been noted is PBXs and other services that implement > Call Forward and Follow-me by spoofing From to be the original caller when > they originate a call from the PBX to the ultimate destination. They do > this so that the called party sees the original caller when they get the > call. > > If we outlaw spoofing, these services wouldn't be able to do that. They > would have to use History or other headers to pass the original calling > party number. > > I believe that we can't continue to allow this kind of spoofing. There > are other headers which are appropriate for use. > > One of the arguments given is that in older systems such as POTS or 2G/3G, > there is no way to get caller ID to show data from the other headers. I > think we have to accept such limitations. Newer systems would not have > that problem of course. > > While it may be unfortunate that something like forward or follow-me > doesn't work as well as it did, I think that it's the right tradeoff. > > Please note that there are another class of calling party number spoofing > circumstances we CAN do something about. Suppose a doctor wants to place a > call on her mobile that appears to come from her office number. In that > case the doctor can authorize the service that arranges that call. They > can get the cert for the office number and authorize the service to place > calls with that number by giving them a cert for that authorization. This > also works for, as an example, a call center placing calls for an > enterprise. > > The difference is, of course, that the "spoofed" number is a number > delegated to the entity spoofing, rather than the forward/follow me case > where the spoofed number is the calling party and the entity spoofing is > authorized by the called party. > > Brian > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --f46d043bdee44f3ffa04de948615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that History-Info should be the solution going for= ward, certainly for SIP networks. =A0

- Alan -


On Fr= i, Jun 7, 2013 at 1:17 PM, Rosen, Brian <Brian.Rosen@neustar.biz= > wrote:
A problem that has been noted is PBXs and ot= her services that implement Call Forward and Follow-me by spoofing From to = be the original caller when they originate a call from the PBX to the ultim= ate destination. =A0They do this so that the called party sees the original= caller when they get the call.

If we outlaw spoofing, these services wouldn't be able to do that. =A0T= hey would have to use History or other headers to pass the original calling= party number.

I believe that we can't continue to allow this kind of spoofing. =A0The= re are other headers which are appropriate for use.

One of the arguments given is that in older systems such as POTS or 2G/3G, = there is no way to get caller ID to show data from the other headers. =A0I = think we have to accept such limitations. =A0Newer systems would not have t= hat problem of course.

While it may be unfortunate that something like forward or follow-me doesn&= #39;t work as well as it did, I think that it's the right tradeoff.

Please note that there are another class of calling party number spoofing c= ircumstances we CAN do something about. =A0Suppose a doctor wants to place = a call on her mobile that appears to come from her office number. =A0In tha= t case the doctor can authorize the service that arranges that call. =A0The= y can get the cert for the office number and authorize the service to place= calls with that number by giving them a cert for that authorization. =A0Th= is also works for, as an example, a call center placing calls for an enterp= rise.

The difference is, of course, that the "spoofed" number is a numb= er delegated to the entity spoofing, rather than the forward/follow me case= where the spoofed number is the calling party and the entity spoofing is a= uthorized by the called party.

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

--f46d043bdee44f3ffa04de948615-- From dcrocker@bbiw.net Fri Jun 7 11:27: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 0458F21F896D for ; Fri, 7 Jun 2013 11:27: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 mcu1bjqvbpfi for ; Fri, 7 Jun 2013 11:26:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17B6221F8617 for ; Fri, 7 Jun 2013 11:26:59 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57IQrIG023454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:26:58 -0700 Message-ID: <51B225E9.8050206@bbiw.net> Date: Fri, 07 Jun 2013 20:26:49 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> In-Reply-To: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 07 Jun 2013 11:26:58 -0700 (PDT) X-Mailman-Approved-At: Fri, 07 Jun 2013 11:27:36 -0700 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:27:04 -0000 On 6/7/2013 7:20 PM, Rosen, Brian wrote: > The fundamental idea that we have here is that you sign a set of > information with a credential, and you pass the signature and a pointer > to the credential in SIP signaling. ... although you say 'credential' rather than 'signature', that all sounds pretty similar to DKIM... the bit of difference probably hinges on whether the extra functionality of a credential is really required, and whether credentials can scale to this use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Fri Jun 7 11:29: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 0F8D121F9925 for ; Fri, 7 Jun 2013 11:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIALYiSlqcaN for ; Fri, 7 Jun 2013 11:29:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7721F8FEB for ; Fri, 7 Jun 2013 11:29:36 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57ITT8k023488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:29:35 -0700 Message-ID: <51B22686.9090704@dcrocker.net> Date: Fri, 07 Jun 2013 20:29:26 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> In-Reply-To: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 07 Jun 2013 11:29:35 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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: Fri, 07 Jun 2013 18:29:41 -0000 On 6/7/2013 7:20 PM, Rosen, Brian wrote: > The fundamental idea that we have here is that you sign a set of > information with a credential, and you pass the signature and a pointer > to the credential in SIP signaling. ... although you say 'credential' rather than 'signature', that all sounds pretty similar to DKIM... the bit of difference probably hinges on whether the extra functionality of a credential is really required, and whether credentials can scale to this use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Fri Jun 7 11:33: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 0059821F9931 for ; Fri, 7 Jun 2013 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 4rWC6dIVdp4y for ; Fri, 7 Jun 2013 11:33:18 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2121F992C for ; Fri, 7 Jun 2013 11:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370630172; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=FDlofwNHGc zFYFv55wkuEwOfrF9aHAWDXzNfETXhEr8=; b=BuOJBZrkLN2F/k96xdxKJ7WCh1 uqnKOXKKYYECNWhYURWP5RICp2Vm3js/DuDL/2iZOf3WTR4FEpNVs2GUHAcg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24782137; Fri, 07 Jun 2013 14:36:11 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:33:09 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:33:03 -0400 From: "Rosen, Brian" To: Dave Crocker Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq1O2AgAABvoA= Date: Fri, 7 Jun 2013 18:33:03 +0000 Message-ID: <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> In-Reply-To: <51B225E9.8050206@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3r9z5We1CP3eSVbkByal2w== Content-Type: text/plain; charset="us-ascii" Content-ID: <5F2FE7FFFBEF3749ABE8B7E960BAAB7D@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:33:22 -0000 The idea is that the credential comes with the number delegation. When you get a number (or a range of numbers if you are a service provider)= , you get a credential that authorizes use of that number. That scales. What is needed is a way to prove the provenance of the delegation. The roo= t of trust is the regulator, or a contractor of the regulator, which, in al= l countries, controls the number space. There is a delegation path that ex= ists for numbers. We create a PKI that exactly mirrors that path. In countries with number portability, there are some complications, but in = all cases, there is a clear delegation path for the numbers, and the cert c= hain follows it. Brian On Jun 7, 2013, at 2:26 PM, Dave Crocker wrote: > On 6/7/2013 7:20 PM, Rosen, Brian wrote: >> The fundamental idea that we have here is that you sign a set of >> information with a credential, and you pass the signature and a pointer >> to the credential in SIP signaling. > ... >=20 >=20 > although you say 'credential' rather than 'signature', that all sounds pr= etty similar to DKIM... >=20 > the bit of difference probably hinges on whether the extra functionality = of a credential is really required, and whether credentials can scale to th= is use. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dcrocker@bbiw.net Fri Jun 7 11:36: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 D401C21F85E0 for ; Fri, 7 Jun 2013 11:36:57 -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 JB-Z8f3VeSq4 for ; Fri, 7 Jun 2013 11:36:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1821F9948 for ; Fri, 7 Jun 2013 11:36:52 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57IakUb023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:36:51 -0700 Message-ID: <51B2283A.6070207@bbiw.net> Date: Fri, 07 Jun 2013 20:36:42 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> In-Reply-To: <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 07 Jun 2013 11:36:52 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:36:57 -0000 On 6/7/2013 8:33 PM, Rosen, Brian wrote: > In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it. If you certify operators rather than number blocks, then you have a weaker model for /detecting/ misuse -- an operator can use a number that isn't delegated to them -- but you retain sufficient accountability and number portability isn't an issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hgs@cs.columbia.edu Fri Jun 7 11:37: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 AC7EB21F89D5 for ; Fri, 7 Jun 2013 11:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 8jw1DfgT+0Ir for ; Fri, 7 Jun 2013 11:36:58 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8E821F85E0 for ; Fri, 7 Jun 2013 11:36:58 -0700 (PDT) Received: from [172.20.18.244] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r57IaqEw016378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 14:36:53 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_386EE8EA-53C0-4731-863E-D4D6D7479969" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: Date: Fri, 7 Jun 2013 14:37:01 -0400 Message-Id: References: , <005401ce6303$61afdc90$250f95b0$@shockey.us> <3318BDF1-3F8B-4867-AEEE-16183949B000@att.com> <0A11FD66-5F73-406B-A86B-74252CA5A8D3@brianrosen.net> <9A320CED-B3A1-4511-BCED-4E8997C64472@brianrosen.net> <8BDF0DE5-4250-4499-8474-E7BAB2698A06@cs.columbia.edu> <1919B30B-BA7E-4E48-A273-DED4720B6298@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "stir@ietf.org" , Hadriel Kaplan , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:37:02 -0000 --Apple-Mail=_386EE8EA-53C0-4731-863E-D4D6D7479969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The origin of the term "pink carrier" is in the email spam area, and is = explained in http://en.wikipedia.org/wiki/Email_spam My take is that "pink carrier" refers to entities willing to host = robocallers and other scum, rather than just carriers that don't = validate. There's obviously a fluid boundary between having robocallers = be part of your business plan and being insufficiently diligent. Henning On Jun 7, 2013, at 1:49 PM, Brian Rosen wrote: > Henning can tell us more, but I understand that at least in the U.S., = most of the bad calls are coming from carriers that are not = certificated, and are SIP connected to a certificated carrier. They = purchase numbers from that carrier. They are SIP only. >=20 > Many of the certificated carriers currently do not check the validity = of the calling party number for calls arriving on their wholesale side = via SIP. It's pretty difficult - the upstream service provider could = have millions of numbers spread across all the rate centers the = certificated carrier has service in. Martin can speak to whether AT&T = tries to do that. >=20 > I certainly do worry about a pink carrier with an SS7 connection. = There are some certificated carriers that provide such services and if = we close off the SIP interconnect path, they may seek out the SS7 path. = That would be bad because then we have no green carrier before we get to = SS7. It may be that we can work out ways to encourage such carriers to = migrate their customers to SIP trunks rather than PRI and then be in a = place to fix the issues. >=20 > Brian >=20 > On Jun 7, 2013, at 1:33 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> Hmmm... maybe I'm using a different definition for "pink carrier". I = was thinking a pink carrier was an origination or transit provider that = doesn't care whether it's caller-id's are bogus or not. Not because = it's malicious or setting invalid caller-ids itself, but just because it = receives it that way form its customers and doesn't know better or = doesn't care so long as it gets paid. I know some carriers like that, = and they have PSTN gateways upstream. As far as I know they're not "SS7 = carriers" in that they don't have STPs and point codes - but they have = SIP-PRI gateways, and their PRIs go to SS7 carriers. >>=20 >> Are you saying that those are the pink carriers, but that usually = they've got SIP upstream to their next transit carrier; or are you = saying those are the green carriers and the pink carriers are their = customers, the ones setting bogus caller-ids on purpose? >>=20 >> -hadriel >>=20 >>=20 >> On Jun 7, 2013, at 1:10 PM, Brian Rosen wrote: >>=20 >>> Turns out that the "pink carriers" don't own the PSTN interconnects = by and large. They are SIP only. They pass calls to a certificated = carrier who is actually pretty trustworthily mostly. That isn't always = true, but it's mostly true. >>>=20 >>> I'm still not sure we can get those carriers to implement a validity = check and cause the SS7 gateways to set the not-evil bit, but it may be = possible. >>>=20 >>> The out of band DB still seems to be a better solution but this = could help. >>>=20 >>> Brian >>>=20 >>> On Jun 7, 2013, at 1:02 PM, Hadriel Kaplan = wrote: >>>=20 >>>>=20 >>>> I'm not sure I understand the logic here. >>>> Why would we trust a "not-evil" bit coming in from SS7/ISUP? >>>> Why wouldn't all pink carriers just start setting that bit? >>>>=20 >>>> At some point you said we can trust the SS7 carrier, but really we = can't - or rather, it's too late by then. The pink carriers egress = their calls on PRIs/etc. on gateways they own. The next transit carrier = has no idea if the transmitted CgPN is valid or not. >>>> Did I miss something? >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Jun 7, 2013, at 11:36 AM, Henning Schulzrinne = wrote: >>>>=20 >>>>> I was thinking of a codepoint for CPC, not an addition to the = protocol. >>>>>=20 >>>>> On Jun 7, 2013, at 11:21 AM, "DOLLY, MARTIN C" = wrote: >>>>>=20 >>>>>> I do not believe we can add anything to ISUP >>>>>>=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 >>=20 >=20 >=20 --Apple-Mail=_386EE8EA-53C0-4731-863E-D4D6D7479969 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


My take is that "pink = carrier" refers to entities willing to host robocallers and other scum, = rather than just carriers that don't validate. There's obviously a fluid = boundary between having robocallers be part of your business plan and = being insufficiently = diligent.

Henning

On Jun 7, = 2013, at 1:49 PM, Brian Rosen <br@brianrosen.net> = wrote:

Henning can tell us more, but I understand that at least = in the U.S., most of the bad calls are coming from carriers that are not = certificated, and are SIP connected to a certificated carrier. =  They purchase numbers from that carrier.  They are SIP = only.

Many of the certificated carriers currently do not check = the validity of the calling party number for calls arriving on their = wholesale side via SIP.  It's pretty difficult - the upstream = service provider could have millions of numbers spread across all the = rate centers the certificated carrier has service in.  Martin can = speak to whether AT&T tries to do that.

I certainly do worry = about a pink carrier with an SS7 connection.  There are some = certificated carriers that provide such services and if we close off the = SIP interconnect path, they may seek out the SS7 path.  That would = be bad because then we have no green carrier before we get to SS7. =  It may be that we can work out ways to encourage such carriers to = migrate their customers to SIP trunks rather than PRI and then be in a = place to fix the issues.

Brian

On Jun 7, 2013, at 1:33 PM, = Hadriel Kaplan <hadriel.kaplan@oracle.com>= ; wrote:


Hmmm... maybe I'm using a = different definition for "pink carrier".  I was thinking a pink = carrier was an origination or transit provider that doesn't care whether = it's caller-id's are bogus or not.  Not because it's malicious or = setting invalid caller-ids itself, but just because it receives it that = way form its customers and doesn't know better or doesn't care so long = as it gets paid.  I know some carriers like that, and they have = PSTN gateways upstream.  As far as I know they're not "SS7 = carriers" in that they don't have STPs and point codes - but they have = SIP-PRI gateways, and their PRIs go to SS7 carriers.

Are you = saying that those are the pink carriers, but that usually they've got = SIP upstream to their next transit carrier; or are you saying those are = the green carriers and the pink carriers are their customers, the ones = setting bogus caller-ids on purpose?

-hadriel


On Jun = 7, 2013, at 1:10 PM, Brian Rosen <br@brianrosen.net> = wrote:

Turns out that the "pink = carriers" don't own the PSTN interconnects by and large.  They are = SIP only.  They pass calls to a certificated carrier who is = actually pretty trustworthily mostly.  That isn't always true, but = it's mostly true.

I'm still not sure we can get those carriers to = implement a validity check and cause the SS7 gateways to set the = not-evil bit, but it may be possible.

The out of band DB still = seems to be a better solution but this could = help.

Brian

On Jun 7, 2013, at 1:02 PM, Hadriel Kaplan = <hadriel.kaplan@oracle.com>= ; wrote:


I'm not sure I understand = the logic here.
Why would we trust a "not-evil" bit coming in from = SS7/ISUP?
Why wouldn't all pink carriers just start setting that = bit?

At some point you said we can trust the SS7 carrier, but = really we can't - or rather, it's too late by then.  The pink = carriers egress their calls on PRIs/etc. on gateways they own.  The = next transit carrier has no idea if the transmitted CgPN is valid or = not.
Did I miss something?

-hadriel


On Jun 7, 2013, = at 11:36 AM, Henning Schulzrinne <hgs@cs.columbia.edu> = wrote:

I was thinking of a codepoint = for CPC, not an addition to the protocol.

On Jun 7, 2013, at = 11:21 AM, "DOLLY, MARTIN C" <md3135@att.com> = wrote:

I do not believe we can add = anything to = ISUP

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


_________________= ______________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir



=

= --Apple-Mail=_386EE8EA-53C0-4731-863E-D4D6D7479969-- From dhc2@dcrocker.net Fri Jun 7 11:37: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 938F421F85E0 for ; Fri, 7 Jun 2013 11:37: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 N56xiBnKbyxH for ; Fri, 7 Jun 2013 11:37:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4B8421F86D5 for ; Fri, 7 Jun 2013 11:37:15 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57Ib8U1023659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:37:14 -0700 Message-ID: <51B22851.3050402@dcrocker.net> Date: Fri, 07 Jun 2013 20:37:05 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> In-Reply-To: <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 07 Jun 2013 11:37:15 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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: Fri, 07 Jun 2013 18:37:20 -0000 On 6/7/2013 8:33 PM, Rosen, Brian wrote: > In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it. If you certify operators rather than number blocks, then you have a weaker model for /detecting/ misuse -- an operator can use a number that isn't delegated to them -- but you retain sufficient accountability and number portability isn't an issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Fri Jun 7 11:37: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 1853C21F96EC for ; Fri, 7 Jun 2013 11:37:49 -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=[AWL=-0.000, BAYES_00=-2.599, 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 ZWCjsbbIkoKi for ; Fri, 7 Jun 2013 11:37:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91921F86D5 for ; Fri, 7 Jun 2013 11:37:42 -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 r57IbdMT009669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 18:37: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 r57Ibe3a026576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 18:37:41 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57Ibeec011511; Fri, 7 Jun 2013 18:37:40 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 11:36:46 -0700 MIME-Version: 1.0 Message-ID: Date: Fri, 7 Jun 2013 11:36:46 -0700 (PDT) From: Hadriel Kaplan To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> In-Reply-To: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:37:49 -0000 On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" = wrote: > After reading it, I am unclear if a canonicalized e.164 would make it = through. The reasons given seem to indicate they would. They change = domains, they change prefixes, but they don't seem to change the actual = telephone number. > Can we come up with examples where a canonicalized e.164 would NOT = pass end to end? Depends on how you mean this - do you mean can we avoid putting a = canonical version into a separate header, and instead keep it in the = From/To? I don't know that we can really know the answer to that universally. There are some times when the From/To username numbers are changed for = reasons other than what I had in that old draft. For example sometimes = they're pre-pended with prefixes used for routing purposes, but the = prefix is later removed before egressing the network. That probably = wouldn't matter so long as it got inserted after the signer and removed = before the verifier, or the signer/verifier were aware of it. Also the = =46rom number is sometimes replaced with a general company number, to = hide the specific agent/attendant making a call; but that would = hopefully happen before signing so it won't matter. Sometimes the To is = changed due to call forwarding/hunting/selection to be the new = destination number, despite the RFCs that say otherwise. -hadriel From hgs@cs.columbia.edu Fri Jun 7 11:40: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 8C51321F8D0D for ; Fri, 7 Jun 2013 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 uuk5-Nsh+OKq for ; Fri, 7 Jun 2013 11:40:24 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8B37B21F96EC for ; Fri, 7 Jun 2013 11:40:24 -0700 (PDT) Received: from [172.20.18.244] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r57IeNZf005652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 14:40:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: Date: Fri, 7 Jun 2013 14:40:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:40:29 -0000 On forwarding, it would seem that, in many cases, the validation is done = *before* the forwarding happens. For example, the typical follow-me on a = PBX is done by my (trusted) PBX, and it would do the validation on the = incoming call. Same for carriers that offer find-me/follow-me as a = consumer feature. On Jun 7, 2013, at 2:36 PM, Hadriel Kaplan = wrote: >=20 > On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" = wrote: >=20 >> After reading it, I am unclear if a canonicalized e.164 would make it = through. The reasons given seem to indicate they would. They change = domains, they change prefixes, but they don't seem to change the actual = telephone number. >> Can we come up with examples where a canonicalized e.164 would NOT = pass end to end? >=20 > Depends on how you mean this - do you mean can we avoid putting a = canonical version into a separate header, and instead keep it in the = From/To? > I don't know that we can really know the answer to that universally. >=20 > There are some times when the From/To username numbers are changed for = reasons other than what I had in that old draft. For example sometimes = they're pre-pended with prefixes used for routing purposes, but the = prefix is later removed before egressing the network. That probably = wouldn't matter so long as it got inserted after the signer and removed = before the verifier, or the signer/verifier were aware of it. Also the = =46rom number is sometimes replaced with a general company number, to = hide the specific agent/attendant making a call; but that would = hopefully happen before signing so it won't matter. Sometimes the To is = changed due to call forwarding/hunting/selection to be the new = destination number, despite the RFCs that say otherwise. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From brian.rosen@neustar.biz Fri Jun 7 11:43: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 3B35421F9347 for ; Fri, 7 Jun 2013 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Nmk4ebvfYswR for ; Fri, 7 Jun 2013 11:43:27 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED6621F8EFE for ; Fri, 7 Jun 2013 11:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370630783; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=hPRxKO9gTm p4aCCJtY4/VnmUkXjxetTtRipT0DxQ3gQ=; b=LZedIYYah4g5FWXO/HcBIRBeUS lnigfuZ7MdEP7E8fUDR4wmlAhgeOnzgydibpxd1+PpQ42uOERnglmeKqKESw== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24782653; Fri, 07 Jun 2013 14:46:22 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:43:20 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:43:16 -0400 From: "Rosen, Brian" To: Dave Crocker Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq1O2AgAABvoCAAAEFAIAAAdMA Date: Fri, 7 Jun 2013 18:43:16 +0000 Message-ID: <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> In-Reply-To: <51B2283A.6070207@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 84dpQV7eFcyQ2NYoQzNrCg== Content-Type: text/plain; charset="us-ascii" Content-ID: <451A2570F53C624289123918B5837D7A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:43:31 -0000 I would say it's impossible to certify operators. You could make a case for certifying AT&T. But how do you decide which other carriers are good guys? Probably impossible, at least in any reasonable deployment time frame. Portability is actually fairly simple. You provide a service that validates= that a number remains a part of a range and you get a new cert when a numb= er ports. It's a complication, but the solution is straightforward, scalab= le, and secure. There are countries that have a forwarding model for porta= bility where the range holder forwards calls to the current holder. The ce= rt path follows that path - the original number holder issues a cert to the= current holder that it is authorized the use of the number. Brian On Jun 7, 2013, at 2:36 PM, Dave Crocker wrote: > On 6/7/2013 8:33 PM, Rosen, Brian wrote: >> In countries with number portability, there are some complications, but = in all cases, there is a clear delegation path for the numbers, and the cer= t chain follows it. >=20 >=20 > If you certify operators rather than number blocks, then you have a weake= r model for /detecting/ misuse -- an operator can use a number that isn't d= elegated to them -- but you retain sufficient accountability and number por= tability isn't an issue. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Fri Jun 7 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 4F2AE21F861F for ; Fri, 7 Jun 2013 11:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 CuOam+5lDzzv for ; Fri, 7 Jun 2013 11:53:36 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21921F95DD for ; Fri, 7 Jun 2013 11:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370631696; x=1685963347; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=91/rjWdQN8 sm/+v4jvK+8ESJq6vgzGT+KrlDiBW22uU=; b=RJhSl3WK4KTSD+AoUQQck4ogow t+nVSSQTWAdLyBH7BQ8ukL+lRHFTjSCa1m29f6EfRCkBlg2fZqReeq5zXb2A== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.25936618; Fri, 07 Jun 2013 15:01:35 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 14:53:26 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 14:53:20 -0400 From: "Rosen, Brian" To: Henning Schulzrinne Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq17QAgAABDgCAAAOTAA== Date: Fri, 7 Jun 2013 18:53:20 +0000 Message-ID: <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3S78sA56zvh6OYm20cVMSg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Hadriel Kaplan , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:53:40 -0000 Sure, but can your forward-to device/service validate the call from your PB= X? It could not if the calling party number was the original party and not the= PBX. The problem is that when the forward-to device gets the call, the ca= lled party number is it's own, and the calling party number is the original= calling party, not the PBX. This is a different call, with a different To= . It should have a different From, but they are spoofing the From. The de= vice/service could not validate that because the actual originator, the PBX= , doesn't have the credential for the number in From. Brian On Jun 7, 2013, at 2:40 PM, Henning Schulzrinne wrote= : > On forwarding, it would seem that, in many cases, the validation is done = *before* the forwarding happens. For example, the typical follow-me on a PB= X is done by my (trusted) PBX, and it would do the validation on the incomi= ng call. Same for carriers that offer find-me/follow-me as a consumer featu= re. >=20 > On Jun 7, 2013, at 2:36 PM, Hadriel Kaplan wr= ote: >=20 >>=20 >> On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" wro= te: >>=20 >>> After reading it, I am unclear if a canonicalized e.164 would make it t= hrough. The reasons given seem to indicate they would. They change domain= s, they change prefixes, but they don't seem to change the actual telephone= number. >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>=20 >> Depends on how you mean this - do you mean can we avoid putting a canoni= cal version into a separate header, and instead keep it in the From/To? >> I don't know that we can really know the answer to that universally. >>=20 >> There are some times when the From/To username numbers are changed for r= easons other than what I had in that old draft. For example sometimes they= 're pre-pended with prefixes used for routing purposes, but the prefix is l= ater removed before egressing the network. That probably wouldn't matter s= o long as it got inserted after the signer and removed before the verifier,= or the signer/verifier were aware of it. Also the From number is sometime= s replaced with a general company number, to hide the specific agent/attend= ant making a call; but that would hopefully happen before signing so it won= 't matter. Sometimes the To is changed due to call forwarding/hunting/sele= ction to be the new destination number, despite the RFCs that say otherwise= . >>=20 >> -hadriel >>=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 dhc2@dcrocker.net Fri Jun 7 11: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 4D54C21F96EB for ; Fri, 7 Jun 2013 11:53:45 -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 jaSLhMK289x7 for ; Fri, 7 Jun 2013 11:53:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C221F95DD for ; Fri, 7 Jun 2013 11:53:40 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57IrXvM024040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 11:53:39 -0700 Message-ID: <51B22C29.8010502@dcrocker.net> Date: Fri, 07 Jun 2013 20:53:29 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> In-Reply-To: <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 07 Jun 2013 11:53:40 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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: Fri, 07 Jun 2013 18:53:45 -0000 On 6/7/2013 8:43 PM, Rosen, Brian wrote: > I would say it's impossible to certify operators. > > You could make a case for certifying AT&T. > > But how do you decide which other carriers are good guys? By many measures, no one is a good guy. But some guys are authorized. For example, anyone who is assigned a number block is authorized. Certs tend to carry an implication of goodness. My suggestion is more modest, to seek accountability through authenticity. Have such folk register a signing domain in a table of authorized folk. Anything signed has the name queried to that table. This verifies that they are authorized as an operator. It doesn't certify their goodness or even their authorization for a number block, but it means they are on the hook for their bad behavior, because you really do know who they are. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hgs@cs.columbia.edu Fri Jun 7 11:54: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 E94EE21F96EB for ; Fri, 7 Jun 2013 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 8Ler0By-YjH3 for ; Fri, 7 Jun 2013 11:54:46 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0628121F861F for ; Fri, 7 Jun 2013 11:54:45 -0700 (PDT) Received: from [172.20.18.244] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r57Ise2V022596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 14:54:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> Date: Fri, 7 Jun 2013 14:54:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 18:54:52 -0000 I agree it's difficult to certify goodness, but traceability and = accountability may be a bit easier, as these carriers register via NECA = to get an OCN, and this requires significant paper work and $250 = application fee. If a carrier with an OCN turns out to be a rogue, it is = then relatively easy to blacklist them and I suspect NECA would not take = kindly to an attempt to register hundreds of mailboxes. On Jun 7, 2013, at 2:43 PM, "Rosen, Brian" = wrote: > I would say it's impossible to certify operators. >=20 > You could make a case for certifying AT&T. >=20 > But how do you decide which other carriers are good guys? >=20 > Probably impossible, at least in any reasonable deployment time frame. >=20 > Portability is actually fairly simple. You provide a service that = validates that a number remains a part of a range and you get a new cert = when a number ports. It's a complication, but the solution is = straightforward, scalable, and secure. There are countries that have a = forwarding model for portability where the range holder forwards calls = to the current holder. The cert path follows that path - the original = number holder issues a cert to the current holder that it is authorized = the use of the number. From dhc2@dcrocker.net Fri Jun 7 12:00: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 1E8EB21F9969 for ; Fri, 7 Jun 2013 12:00: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 xMvAzKYkAOwr for ; Fri, 7 Jun 2013 12:00:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10A21F96EC for ; Fri, 7 Jun 2013 12:00:14 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57J00tL024325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 12:00:06 -0700 Message-ID: <51B22DAC.4070608@dcrocker.net> Date: Fri, 07 Jun 2013 20:59:56 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> In-Reply-To: <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 07 Jun 2013 12:00:07 -0700 (PDT) Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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: Fri, 07 Jun 2013 19:00:21 -0000 On 6/7/2013 8:54 PM, Henning Schulzrinne wrote: > I agree it's difficult to certify goodness, but traceability and accountability may be a bit easier, as these carriers register via NECA to get an OCN, and this requires significant paper work and $250 application fee. If a carrier with an OCN turns out to be a rogue, it is then relatively easy to blacklist them and I suspect NECA would not take kindly to an attempt to register hundreds of mailboxes. The subversive design and operations message of the DKIM approach is that accountability is more tractable than building in 'reputation' to the core of the mechanism. FWIW, there's been some effort to extract the core DKIM mechanisms out from DKIM, to make them easier to provide to other services: Doseta (DOmain SEcurity TAgging) www.trusteddomain.org/doseta.html d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Fri Jun 7 12:01: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 70D1621F997B for ; Fri, 7 Jun 2013 12:01:03 -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=[AWL=-0.000, BAYES_00=-2.599, 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 lC9WBTebqznC for ; Fri, 7 Jun 2013 12:00:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9494721F9956 for ; Fri, 7 Jun 2013 12:00: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 r57J0Vbl016128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 19:00:32 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 r57J0Ubh006059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 19:00:31 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57J0UXt013149; Fri, 7 Jun 2013 19:00:30 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 11:58:48 -0700 MIME-Version: 1.0 Message-ID: Date: Fri, 7 Jun 2013 11:58:48 -0700 (PDT) From: Hadriel Kaplan To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> In-Reply-To: <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:01:04 -0000 On Jun 7, 2013, at 2:53 PM, "Rosen, Brian" = wrote: > Sure, but can your forward-to device/service validate the call from = your PBX? >=20 > It could not if the calling party number was the original party and = not the PBX. The problem is that when the forward-to device gets the = call, the called party number is it's own, and the calling party number = is the original calling party, not the PBX. This is a different call, = with a different To. It should have a different From, but they are = spoofing the From. The device/service could not validate that because = the actual originator, the PBX, doesn't have the credential for the = number in From. Arguably they're not "spoofing" - they're just routing the call, similar = to a transit. Granted it's a new "call" at a SIP protocol level, but at = the higher "who's calling me for this call?" level, the PBX should leave = the =46rom alone to be the original caller. -hadriel From brian.rosen@neustar.biz Fri Jun 7 12:02: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 2EC4321F8994 for ; Fri, 7 Jun 2013 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-CzikGGpIp9 for ; Fri, 7 Jun 2013 12:02:17 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 320E421F96B1 for ; Fri, 7 Jun 2013 12:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370631901; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=OgodF9NCw2 AxQ0jBfKsVLbORMU88wbwffcvS5NSflUo=; b=QsIfqgqi+dY5NQsmW+5mpNhOfO bDvRe6rG9MNoDxCjFuFQJwPN+A5Ngb3r4hdOAcrpNQrVmI+FfacesAQa3t7A== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24783578; Fri, 07 Jun 2013 15:05:00 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 15:01:58 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 15:01:55 -0400 From: "Rosen, Brian" To: Henning Schulzrinne Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq1O2AgAABvoCAAAEFAIAAAdMAgAADPYCAAAH6AA== Date: Fri, 7 Jun 2013 19:01:55 +0000 Message-ID: <42E4DFC6-1DAF-4342-9CB3-2EFDF728C7C1@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> In-Reply-To: <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: R9StuHld0Z8tzCssJRFYSw== Content-Type: text/plain; charset="us-ascii" Content-ID: <4B5CEA01F52A974BA88FE8FCB03D33A6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Dave Crocker , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:02:21 -0000 Okay, but what is "rogue"? Suppose they do as Hadriel suggests, and accept a PRI without checking call= ing party number to see it's one of theirs. Is that "rogue"? As you say, some of these calls skate a line on whether they are legal or n= ot. But even if they are legal, then the caller still could have a reasona= ble expectation of the ID being accurate. If you keep to the notion that we're not trying to designate good guys but = instead trying to determine if the calling party number is accurate, then u= sing the cert-follows-number-delegation makes things uniformly straightforw= ard. Brian On Jun 7, 2013, at 2:54 PM, Henning Schulzrinne wrote= : > I agree it's difficult to certify goodness, but traceability and accounta= bility may be a bit easier, as these carriers register via NECA to get an O= CN, and this requires significant paper work and $250 application fee. If a= carrier with an OCN turns out to be a rogue, it is then relatively easy to= blacklist them and I suspect NECA would not take kindly to an attempt to r= egister hundreds of mailboxes. >=20 > On Jun 7, 2013, at 2:43 PM, "Rosen, Brian" wrot= e: >=20 >> I would say it's impossible to certify operators. >>=20 >> You could make a case for certifying AT&T. >>=20 >> But how do you decide which other carriers are good guys? >>=20 >> Probably impossible, at least in any reasonable deployment time frame. >>=20 >> Portability is actually fairly simple. You provide a service that valida= tes that a number remains a part of a range and you get a new cert when a n= umber ports. It's a complication, but the solution is straightforward, sca= lable, and secure. There are countries that have a forwarding model for po= rtability where the range holder forwards calls to the current holder. The= cert path follows that path - the original number holder issues a cert to = the current holder that it is authorized the use of the number. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Fri Jun 7 12:03: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 1E66821F9711 for ; Fri, 7 Jun 2013 12:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 lYJByQJaOEiK for ; Fri, 7 Jun 2013 12:03:16 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8E39E21F96B1 for ; Fri, 7 Jun 2013 12:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370632282; x=1685963347; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=iwTS/O42wm w7zjTMRpm5JHL4o11JQKNAPu3fRLnRGVo=; b=Zi2hnGhOPBynSdWp6kdqewZjTd 0PxxGWG4ZNMjoFtmYoR3r63i9Uie0ca/m+ev4UV4dxlV6bQEUgW/zQWTYwcg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.25937124; Fri, 07 Jun 2013 15:11:21 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 15:03:11 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 15:03:07 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq17QAgAABDgCAAAOTAIAAAYcAgAABNAA= Date: Fri, 7 Jun 2013 19:03:07 +0000 Message-ID: <33CF61D1-CE29-45A9-B6A9-D4FB57A5266C@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: nZrr7k77cTYY7nqcW6bE8Q== Content-Type: text/plain; charset="us-ascii" Content-ID: <1D0BB06EAD1EFE43B2A8D900B9C76978@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Henning Schulzrinne , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:03:21 -0000 Actually they are not. If they were, they would use redirect. They are terminating the original call and originating a new call. Brian On Jun 7, 2013, at 2:58 PM, Hadriel Kaplan wrot= e: >=20 > On Jun 7, 2013, at 2:53 PM, "Rosen, Brian" wrot= e: >=20 >> Sure, but can your forward-to device/service validate the call from your= PBX? >>=20 >> It could not if the calling party number was the original party and not = the PBX. The problem is that when the forward-to device gets the call, the= called party number is it's own, and the calling party number is the origi= nal calling party, not the PBX. This is a different call, with a different= To. It should have a different From, but they are spoofing the From. The= device/service could not validate that because the actual originator, the = PBX, doesn't have the credential for the number in From. >=20 > Arguably they're not "spoofing" - they're just routing the call, similar = to a transit. Granted it's a new "call" at a SIP protocol level, but at th= e higher "who's calling me for this call?" level, the PBX should leave the = >From alone to be the original caller. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Jun 7 12:06: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 071E021F997B for ; Fri, 7 Jun 2013 12:06:51 -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=[AWL=-0.000, BAYES_00=-2.599, 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 6+i2yZnhwwcY for ; Fri, 7 Jun 2013 12:06:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DD82421F995C for ; Fri, 7 Jun 2013 12:06:45 -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 r57J6dGW005054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 19:06:39 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 r57J6e2A015559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 19:06:41 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 r57J6eH9002468; Fri, 7 Jun 2013 19:06:40 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 12:06:40 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51B22C29.8010502@dcrocker.net> Date: Fri, 7 Jun 2013 15:06:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B31FD0C-40CB-4E0A-ABA6-6F7D7CAFF3D7@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:06:51 -0000 On Jun 7, 2013, at 2:53 PM, Dave Crocker wrote: > By many measures, no one is a good guy. But some guys are authorized. = For example, anyone who is assigned a number block is authorized. > Certs tend to carry an implication of goodness. My suggestion is more = modest, to seek accountability through authenticity. >=20 > Have such folk register a signing domain in a table of authorized = folk. Anything signed has the name queried to that table. This = verifies that they are authorized as an operator. > It doesn't certify their goodness or even their authorization for a = number block, but it means they are on the hook for their bad behavior, = because you really do know who they are. Essentially a reputation system, which will work so long as it's = national operators doing this thing, because they're known and there = aren't that many of them in any given country. That was basically one of the premises behind this being useful: http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 Although I admit it might get to the point of being this: http://xkcd.com/1181/ -hadriel From brian.rosen@neustar.biz Fri Jun 7 12:09: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 88DAC21F9928 for ; Fri, 7 Jun 2013 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 VRVeC7-HdW0S for ; Fri, 7 Jun 2013 12:08:58 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id F280E21F96C6 for ; Fri, 7 Jun 2013 12:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370632313; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ockIg/olFx /hUHIRAWKN6oHaWbzH8+mLH+9cUhGlueU=; b=psq4METJnWp+w36GmjREH0gqMO lRLqL6QIrh304aWcdB3Si0i4MFkG6Z5dstDSPzpwKmmiOORr7+6fosixq1zQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24783894; Fri, 07 Jun 2013 15:11:52 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 15:08:50 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 15:08:48 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq1O2AgAABvoCAAAEFAIAAAdMAgAAC3YCAAARIAA== Date: Fri, 7 Jun 2013 19:08:48 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> In-Reply-To: <51B22C29.8010502@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: cITk2pWIqrkwykEMAPR8Rw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:09:02 -0000 But then we're creating a table owner, and a criteria to get on the table. It also won't lead to the end state we really want which is the end device = signs and the other end device verifies. Delegation works perfectly fine r= ight down to a single number. It's reasonable to start with service providers signing and checking, but w= e'd like to evolve to end to end. The cert is not carrying any notion of goodness whatsoever. It doesn't eve= n have to identify the holder in any way. All it has to do is prove proven= ance for the number. That's a pretty good model. Brian On Jun 7, 2013, at 2:53 PM, Dave Crocker wrote: > On 6/7/2013 8:43 PM, Rosen, Brian wrote: >> I would say it's impossible to certify operators. >>=20 >> You could make a case for certifying AT&T. >>=20 >> But how do you decide which other carriers are good guys? >=20 >=20 >=20 > By many measures, no one is a good guy. But some guys are authorized. Fo= r example, anyone who is assigned a number block is authorized. >=20 > Certs tend to carry an implication of goodness. My suggestion is more mo= dest, to seek accountability through authenticity. >=20 > Have such folk register a signing domain in a table of authorized folk. = Anything signed has the name queried to that table. This verifies that the= y are authorized as an operator. >=20 > It doesn't certify their goodness or even their authorization for a numbe= r block, but it means they are on the hook for their bad behavior, because = you really do know who they are. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Jun 7 12:10: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 4375E21F99B3 for ; Fri, 7 Jun 2013 12:10:59 -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=[AWL=-0.000, BAYES_00=-2.599, 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 OnVvlNPSg0se for ; Fri, 7 Jun 2013 12:10:53 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D30E221F99B1 for ; Fri, 7 Jun 2013 12:10:53 -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 r57JAhxb008946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 19:10: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 r57JAjQE025317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 19:10:45 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 r57JAi7h025305; Fri, 7 Jun 2013 19:10:45 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 12:08:57 -0700 MIME-Version: 1.0 Message-ID: <737D054B-8798-44B1-9147-D955DC6D98C9@oracle.com> Date: Fri, 7 Jun 2013 12:08:57 -0700 (PDT) From: Hadriel Kaplan To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> <33CF61D1-CE29-45A9-B6A9-D4FB57A5266C@neustar.biz> In-Reply-To: <33CF61D1-CE29-45A9-B6A9-D4FB57A5266C@neustar.biz> X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:10:59 -0000 On Jun 7, 2013, at 3:03 PM, "Rosen, Brian" = wrote: > Actually they are not. If they were, they would use redirect. > They are terminating the original call and originating a new call. As I said: at a SIP protocol level it's a new call. But not at a user = level. >=20 > Brian >=20 > On Jun 7, 2013, at 2:58 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Jun 7, 2013, at 2:53 PM, "Rosen, Brian" = wrote: >>=20 >>> Sure, but can your forward-to device/service validate the call from = your PBX? >>>=20 >>> It could not if the calling party number was the original party and = not the PBX. The problem is that when the forward-to device gets the = call, the called party number is it's own, and the calling party number = is the original calling party, not the PBX. This is a different call, = with a different To. It should have a different From, but they are = spoofing the From. The device/service could not validate that because = the actual originator, the PBX, doesn't have the credential for the = number in From. >>=20 >> Arguably they're not "spoofing" - they're just routing the call, = similar to a transit. Granted it's a new "call" at a SIP protocol = level, but at the higher "who's calling me for this call?" level, the = PBX should leave the =46rom alone to be the original caller. >>=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 brian.rosen@neustar.biz Fri Jun 7 12:14: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 956AD21F96ED for ; Fri, 7 Jun 2013 12:14: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.154, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 xaaS7xrsao0c for ; Fri, 7 Jun 2013 12:14:14 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8F14921F96EC for ; Fri, 7 Jun 2013 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370632629; x=1685984552; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ijVZWzga/i c9NkG3OwkJ8k+cri4YifOct1juwhTTEqg=; b=bafgu7UwHeqOKC5/4PsnqcYzkE AevJwTU1iLkL8TIjpE5hQ51MibpfKs9Bo4p7oO5dVqmRiJ3nVlUfZ82ZiRCA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24784191; Fri, 07 Jun 2013 15:17:08 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 15:14:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Fri, 7 Jun 2013 15:14:04 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq17QAgAABDgCAAAOTAIAAAYcAgAABNACAAAGigIAAAWwA Date: Fri, 7 Jun 2013 19:14:03 +0000 Message-ID: <8A1225AC-CF63-4332-93EB-CA4355A46077@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> <33CF61D1-CE29-45A9-B6A9-D4FB57A5266C@neustar.biz> <737D054B-8798-44B1-9147-D955DC6D98C9@oracle.com> In-Reply-To: <737D054B-8798-44B1-9147-D955DC6D98C9@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: U7n3Gmj48cSkKvtHtJ3lQw== Content-Type: text/plain; charset="us-ascii" Content-ID: <5C561C3BBA0BBB4BBA0CF2166102B9D1@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Henning Schulzrinne , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:14:18 -0000 Okay, but we're working on the SIP protocol. If we are talking about user level, the user wants to know the difference b= etween a call placed directly to his mobile and a call placed to his office= and forwarded by his office to his mobile. And I would not care to get into a discussion of what the UI to distinguish= is :) Brian On Jun 7, 2013, at 3:08 PM, Hadriel Kaplan wrot= e: >=20 > On Jun 7, 2013, at 3:03 PM, "Rosen, Brian" wrot= e: >=20 >> Actually they are not. If they were, they would use redirect. >> They are terminating the original call and originating a new call. >=20 >=20 > As I said: at a SIP protocol level it's a new call. But not at a user le= vel. >=20 >=20 >>=20 >> Brian >>=20 >> On Jun 7, 2013, at 2:58 PM, Hadriel Kaplan w= rote: >>=20 >>>=20 >>> On Jun 7, 2013, at 2:53 PM, "Rosen, Brian" wr= ote: >>>=20 >>>> Sure, but can your forward-to device/service validate the call from yo= ur PBX? >>>>=20 >>>> It could not if the calling party number was the original party and no= t the PBX. The problem is that when the forward-to device gets the call, t= he called party number is it's own, and the calling party number is the ori= ginal calling party, not the PBX. This is a different call, with a differe= nt To. It should have a different From, but they are spoofing the From. T= he device/service could not validate that because the actual originator, th= e PBX, doesn't have the credential for the number in From. >>>=20 >>> Arguably they're not "spoofing" - they're just routing the call, simila= r to a transit. Granted it's a new "call" at a SIP protocol level, but at = the higher "who's calling me for this call?" level, the PBX should leave th= e From alone to be the original caller. >>>=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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc2@dcrocker.net Fri Jun 7 12:17: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 DEC2021F9691 for ; Fri, 7 Jun 2013 12:17:50 -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 OhYc69E1hiRy for ; Fri, 7 Jun 2013 12:17:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E8BFB21F9347 for ; Fri, 7 Jun 2013 12:17:45 -0700 (PDT) Received: from [173.255.178.172] (172.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.172]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r57JHcNd024805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 12:17:44 -0700 Message-ID: <51B231CE.7010908@dcrocker.net> Date: Fri, 07 Jun 2013 21:17:34 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@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]); Fri, 07 Jun 2013 12:17:45 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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: Fri, 07 Jun 2013 19:17:51 -0000 On 6/7/2013 9:08 PM, Rosen, Brian wrote: > But then we're creating a table owner, and a criteria to get on the > table. Credentials have the same requirement. Take a look at your summary of the hierarchy. At each level, it's another table owner. > It also won't lead to the end state we really want which is the end > device signs and the other end device verifies. Sure it can, but not with the signature you've had in mind. (Just to be clear, I'm suggesting consideration of an approach; I'm not sure it's the best one and I'm therefore not pushing for its adoption, merely that it be explored.) Anyone can sign. They sign with a domain they own. So the signature goes with the operator, not with the content (number, message, whatever.) For reference, the summary you gave (credential for a number block) is pretty much the same kind of thing, since it's really the referencing the owner of the block, rather than the number itself. > The cert is not carrying any notion of goodness whatsoever. It > doesn't even have to identify the holder in any way. All it has to > do is prove provenance for the number. > > That's a pretty good model. It's excellent in theory, but has not had a promising history on the open and wooly Internet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Fri Jun 7 12:34: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 4B24321F8EFE for ; Fri, 7 Jun 2013 12:34:26 -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=[AWL=-0.000, BAYES_00=-2.599, 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 Ijonx+bnzPTP for ; Fri, 7 Jun 2013 12:34:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EAC2821F8EF7 for ; Fri, 7 Jun 2013 12:34:18 -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 r57JY9G0031054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 19:34:09 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 r57JYAlb020444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 19:34:11 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57JYAYw020432; Fri, 7 Jun 2013 19:34:10 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 12:34: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: <8A1225AC-CF63-4332-93EB-CA4355A46077@neustar.biz> Date: Fri, 7 Jun 2013 15:34:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <4E2875FB-96B9-499D-A9FA-643176AFFD9A@neustar.biz> <33CF61D1-CE29-45A9-B6A9-D4FB57A5266C@neustar.biz> <737D054B-8798-44B1-9147-D955DC6D98C9@oracle.com> <8A1225AC-CF63-4332-93EB-CA4355A46077@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:34:26 -0000 On Jun 7, 2013, at 3:14 PM, "Rosen, Brian" = wrote: > Okay, but we're working on the SIP protocol. Not really - we're basically trying to work around the SIP protocol = because it's use-in-practice doesn't match the expectations of the RFCs. = That's one of the things that made 4474 D.O.A. on day one, and why we = have INSIPID, and STRAW, etc. PBXes *should* use a 3xx redirect or record-route proxy model for = call-forwarding, but they sometimes don't - not because the call truly = is a new call, but rather because if they don't handle it as a B2BUA = then the call will fail, or be billed incorrectly, etc. > If we are talking about user level, the user wants to know the = difference between a call placed directly to his mobile and a call = placed to his office and forwarded by his office to his mobile. Sure but that's what history-info/diversion was supposed to do, by = identifying the original called number. -hadriel From pkyzivat@alum.mit.edu Fri Jun 7 12: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 43F2521F9931 for ; Fri, 7 Jun 2013 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, 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 uCBdDrhPSWUk for ; Fri, 7 Jun 2013 12:38:09 -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 6D4E321F9928 for ; Fri, 7 Jun 2013 12:38:09 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id lXcp1l00816LCl059Xe8r4; Fri, 07 Jun 2013 19:38:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id lXe81l00U3ZTu2S3SXe8xe; Fri, 07 Jun 2013 19:38:08 +0000 Message-ID: <51B2369F.807@alum.mit.edu> Date: Fri, 07 Jun 2013 15:38:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.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=1370633888; bh=mj4+uOoue4SzIHkw+yw4P3ngBu1P1C9SRdA77AWiX34=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OTiH4V9GCxe2akhSo1Ttet8fITCE0unuNvHomIz+17SJvSt6Dt17bhe+GQ7knxC// t/MsJZMa10M+U7HyFlnUeot6Mvv3kqvL/Q/zisnCMt5FkX+3F1PcykBrVSdcf/7qMM u2L5OTSQaGgDL6qkuWOUZZGjbyV+Dgh/gwyQP/yhRB11Lhh9CIG9Dzzme9e+FphBeQ 3ynSINEuTdOrvEKQ+/EjjAl0+l1CbmiCaUsJZzj7RZdxufx5L7mA5sx4/JYd+BrE4c h+Llk5bqNKgLZb+VnIB0AFmV1lA2IzbpdPZSjSX4BbxRxDhWgdnI5OzykbJNEdRYIH p6HduMhktUm5A== Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:38:14 -0000 On 6/7/13 2:08 PM, Rosen, Brian wrote: > Yes, I'm asking if we can avoid using alternative headers. > > I'll start a thread on call forward/follow-me. > > I think presence of most prefixes would be pretty easy to deal with. I would not expect to see the PBX prefixes (9-1-202-555-1212), because the downstream entities couldn't route if they were there. Are we only talking about NANP, or numbers for anyplace? If you take a valid E.164 number, without the "+", and maybe with or without the country code, and potentially prefixed with arbitrary garbage, I'm pretty sure there is no way to uniquely identify the E.164 number. But maybe you were assuming something else. Thanks, Paul > Can anyone else on the list find examples where prefixes may confuse a canonicalization routine on From/To? > > Brian > On Jun 7, 2013, at 1:58 PM, Hadriel Kaplan wrote: > >> >> On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" wrote: >> >>> After reading it, I am unclear if a canonicalized e.164 would make it through. The reasons given seem to indicate they would. They change domains, they change prefixes, but they don't seem to change the actual telephone number. >>> Can we come up with examples where a canonicalized e.164 would NOT pass end to end? >> >> Depends on how you mean this - do you mean can we avoid putting a canonical version into a separate header, and instead keep it in the From/To? >> I don't know that we can really know the answer to that universally. >> >> There are some times when the From/To username numbers are changed for reasons other than what I had in that old draft. For example sometimes they're pre-pended with prefixes used for routing purposes, but the prefix is later removed before egressing the network. That probably wouldn't matter so long as it got inserted after the signer and removed before the verifier, or the signer/verifier were aware of it. Also the From number is sometimes replaced with a general company number, to hide the specific agent/attendant making a call; but that would hopefully happen before signing so it won't matter. Sometimes the To is changed due to call forwarding/hunting/selection to be the new destination number, despite the RFCs that say otherwise. >> >> -hadriel >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From pkyzivat@alum.mit.edu Fri Jun 7 12:41: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 F223721F995A for ; Fri, 7 Jun 2013 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 aOQSlEy3QnMU for ; Fri, 7 Jun 2013 12:41:29 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7132621F9953 for ; Fri, 7 Jun 2013 12:41:29 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id lRMF1l0010xGWP855XhVmd; Fri, 07 Jun 2013 19:41:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id lXhU1l00p3ZTu2S3YXhUXH; Fri, 07 Jun 2013 19:41:28 +0000 Message-ID: <51B23768.6080700@alum.mit.edu> Date: Fri, 07 Jun 2013 15:41:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> In-Reply-To: <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> 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=1370634089; bh=W2+c6xSBYjy5ejLq5SFSo347/BASOooIZIgqfDrrM5U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PSEiAgq1sErfWmHk1jyXBrQ64Fpxs8G+IZ3qOhbHILBuOT9Zf2keBmbTQtTGzZewk vK3yyYGaXsmfhCb+/Hi2MRqNOAgYIjp+wGY4ncgBXYngAPbVO+HZvRTCZw1BhKlFX6 5FdCKp95QWzsDKmnR2ErG/StEXbYnnyiQ0tc3Gpb5zUS4IPlyrdnjOHtU3ikT9yuTC g/hmUJ+Uk+IMjn2zZNtd+kPYoPH9G6H/tMYdlF72y6BRVDDfNYIoTd4sfi91rs6syh 1PXYbugNK7fFxV5nC5Mi2X/VKQEs/42TASld0UXxShgbOhQU38u8ytUka+Xo4gAJwM XJlg0eu+a1lpg== Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:41:34 -0000 On 6/7/13 2:33 PM, Rosen, Brian wrote: > The idea is that the credential comes with the number delegation. > > When you get a number (or a range of numbers if you are a service provider), you get a credential that authorizes use of that number. > > That scales. > > What is needed is a way to prove the provenance of the delegation. The root of trust is the regulator, or a contractor of the regulator, which, in all countries, controls the number space. There is a delegation path that exists for numbers. We create a PKI that exactly mirrors that path. > > In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it. We have a solution for that: ENUM. If you deploy that with DNSSEC you have it all. All you then need is to deploy ENUM that way. :-) Thanks, Paul > Brian > > On Jun 7, 2013, at 2:26 PM, Dave Crocker wrote: > >> On 6/7/2013 7:20 PM, Rosen, Brian wrote: >>> The fundamental idea that we have here is that you sign a set of >>> information with a credential, and you pass the signature and a pointer >>> to the credential in SIP signaling. >> ... >> >> >> although you say 'credential' rather than 'signature', that all sounds pretty similar to DKIM... >> >> the bit of difference probably hinges on whether the extra functionality of a credential is really required, and whether credentials can scale to this use. >> >> 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 brian.rosen@neustar.biz Fri Jun 7 12:47: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 9214C21F96E1 for ; Fri, 7 Jun 2013 12:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ceUBCwSZ0fd for ; Fri, 7 Jun 2013 12:47:38 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6967921F96E4 for ; Fri, 7 Jun 2013 12:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370634342; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=bnnqMzCOSc OA172K2qHKfYz8DgLns3uSz6HOMbH5NQU=; b=qsZNLAdO1VJPNBAGdc6rGcrE1j uU8XcDT3Lg9o3qYU1bfuODZVjzBrPsgSkJAvIaTUbX0gBk206JZljPmXj1Hg== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19274200; Fri, 07 Jun 2013 15:45:41 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Jun 2013 15:47:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Fri, 7 Jun 2013 15:47:24 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpkq1O2AgAABvoCAAAEFAIAAAdMAgAAC3YCAAARIAIAAAnMAgAAIVgA= Date: Fri, 7 Jun 2013 19:47:24 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> In-Reply-To: <51B231CE.7010908@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pRbRN0SkowhtVfZ6rY22nQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <1B3C0D0DB2D19645A0910117EC3080A7@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:47:49 -0000 On Jun 7, 2013, at 3:17 PM, Dave Crocker wrote: > On 6/7/2013 9:08 PM, Rosen, Brian wrote: > > But then we're creating a table owner, and a criteria to get on the > > table. >=20 > Credentials have the same requirement. Take a look at your summary of > the hierarchy. At each level, it's another table owner. Big difference between a single table of all service providers and each ser= vice provider maintaining a table of its customers. We are asking number resellers to know their customer, but we can hold the = reseller to account if he doesn't. You are proposing a master table. =20 I worry less about the owner of a master table (my employer is good at that= sort of thing), but the criteria is very difficult. >=20 >=20 > > It also won't lead to the end state we really want which is the end > > device signs and the other end device verifies. >=20 > Sure it can, but not with the signature you've had in mind. >=20 > (Just to be clear, I'm suggesting consideration of an approach; I'm not s= ure it's the best one and I'm therefore not pushing for its adoption, merel= y that it be explored.) >=20 > Anyone can sign. They sign with a domain they own. So the signature goe= s with the operator, not with the content (number, message, whatever.) >=20 > For reference, the summary you gave (credential for a number block) is pr= etty much the same kind of thing, since it's really the referencing the own= er of the block, rather than the number itself. I don't agree. It's referencing the block itself. The delegator has to know who he is delegating to, but the cert does not ha= ve to identify the holder in any way. The signing mechanism is dependent o= nly on the delegation model, not the identity of the holder. When things go awry, we will run down the chain asking each level who their= customer is, but the chain itself does not contain that information. >=20 >=20 >=20 > > The cert is not carrying any notion of goodness whatsoever. It > > doesn't even have to identify the holder in any way. All it has to > > do is prove provenance for the number. > > > > That's a pretty good model. >=20 > It's excellent in theory, but has not had a promising history on the open= and wooly Internet. This isn't the open and wooly Internet. It's the telephone network, runnin= g in part on mostly private IP networks. Of course the solution works across the Internet, and many of us would be v= ery pleased if there were lots of calls placed over the Internet with good = end to end source identity. But the problem we're solving is more short te= rm, in a more restricted environment. Brian From hgs@cs.columbia.edu Fri Jun 7 12:53: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 7C16121F9969 for ; Fri, 7 Jun 2013 12:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 HKEGPHhZUzAo for ; Fri, 7 Jun 2013 12:53:14 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 927E621F9964 for ; Fri, 7 Jun 2013 12:53:14 -0700 (PDT) Received: from [172.20.18.244] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r57JrDYG025695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 15:53:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: <51B2369F.807@alum.mit.edu> Date: Fri, 7 Jun 2013 15:53:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:53:20 -0000 On Jun 7, 2013, at 3:38 PM, Paul Kyzivat wrote: > On 6/7/13 2:08 PM, Rosen, Brian wrote: >> Yes, I'm asking if we can avoid using alternative headers. >>=20 >> I'll start a thread on call forward/follow-me. >>=20 >> I think presence of most prefixes would be pretty easy to deal with. = I would not expect to see the PBX prefixes (9-1-202-555-1212), because = the downstream entities couldn't route if they were there. >=20 > Are we only talking about NANP, or numbers for anyplace? >=20 > If you take a valid E.164 number, without the "+", and maybe with or = without the country code, and potentially prefixed with arbitrary = garbage, I'm pretty sure there is no way to uniquely identify the E.164 = number. At least for countries with fixed-length numbers, such as the US, taking = the last 10 digits would seem to work, if the number string is longer = than that. From pkyzivat@alum.mit.edu Fri Jun 7 12:57: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 0D09A21F8AE6 for ; Fri, 7 Jun 2013 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.055, 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 B9TOUh9ZNIG6 for ; Fri, 7 Jun 2013 12:57:01 -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 3AC4321F859B for ; Fri, 7 Jun 2013 12:57:00 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta06.westchester.pa.mail.comcast.net with comcast id lPWu1l0041ei1Bg56XwzZv; Fri, 07 Jun 2013 19:56:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id lXwz1l00R3ZTu2S3kXwzhx; Fri, 07 Jun 2013 19:56:59 +0000 Message-ID: <51B23B0A.7040608@alum.mit.edu> Date: Fri, 07 Jun 2013 15:56:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> 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=1370635019; bh=t1VOvEFXHxyzX7FQJKQ2Ky/zrwzM6YBsmm0yzVEMbfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Fn0Vc+1RuJrFtaWGfrm0ThB6hnNhXvOXpoO5K2WM8jBQOfX/eVLvevW4QMl7MZ84Q vke6ZIC9x0xqRGNKD/cwklmkJdyEdZ8+7/0Rin15Ya5+M4YFdHIP1ezPh3J0+yXi1x ErGBJEO2HDueO6MFrSeYRWjamI912j+HYZqd0hrdmYonx6gceCGdWIflEgm2EHCh5c hsjUzSO1IZzhwAod9AODp3CdWfeOt1ifhqwET304qeHFq+IKQuNvNxUExK0xd/ky1Z gAdoDaDG33O0VbIxvManc0OxrEFcGGbSSA8UXpCqBqsyod3sTyDAqYcSRKYObwIP5I 3wX8p5oqFKfug== Subject: Re: [stir] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 19:57:06 -0000 On 6/7/13 2:23 PM, Alan Johnston wrote: > I think that History-Info should be the solution going forward, > certainly for SIP networks. I expect that there will be a variety of "solutions". We aren't obligated to mandate one. Its only necessary to ban spoofing, and let people decide which alternative they want to use. If H-I was deployed across the full range of equipment out there, I'd expect that correct reporting of calling party would be very spotty. Now that calling is typically cheap enough that most people don't think about it, a simple solution to forwarding is 3xx, and to transfer is basic REFER. Those will get the calling party right. (Except in cases where you *want* the identify of the intermediary to be displayed. And that is the easy case.) Thanks, Paul > - Alan - > > > On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian > wrote: > > A problem that has been noted is PBXs and other services that > implement Call Forward and Follow-me by spoofing From to be the > original caller when they originate a call from the PBX to the > ultimate destination. They do this so that the called party sees > the original caller when they get the call. > > If we outlaw spoofing, these services wouldn't be able to do that. > They would have to use History or other headers to pass the > original calling party number. > > I believe that we can't continue to allow this kind of spoofing. > There are other headers which are appropriate for use. > > One of the arguments given is that in older systems such as POTS or > 2G/3G, there is no way to get caller ID to show data from the other > headers. I think we have to accept such limitations. Newer systems > would not have that problem of course. > > While it may be unfortunate that something like forward or follow-me > doesn't work as well as it did, I think that it's the right tradeoff. > > Please note that there are another class of calling party number > spoofing circumstances we CAN do something about. Suppose a doctor > wants to place a call on her mobile that appears to come from her > office number. In that case the doctor can authorize the service > that arranges that call. They can get the cert for the office > number and authorize the service to place calls with that number by > giving them a cert for that authorization. This also works for, as > an example, a call center placing calls for an enterprise. > > The difference is, of course, that the "spoofed" number is a number > delegated to the entity spoofing, rather than the forward/follow me > case where the spoofed number is the calling party and the entity > spoofing is authorized by the called party. > > 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 hadriel.kaplan@oracle.com Fri Jun 7 13:10: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 E696E21F9991 for ; Fri, 7 Jun 2013 13:10:21 -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=[AWL=-0.000, BAYES_00=-2.599, 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 BtfTjEtW+nrw for ; Fri, 7 Jun 2013 13:10:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8209921F998C for ; Fri, 7 Jun 2013 13:10:16 -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 r57KAC35031960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 20:10:13 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 r57KADhH000759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 20:10:14 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57KAD7e000741; Fri, 7 Jun 2013 20:10:13 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-155-163.vpn.oracle.com (/10.154.155.163) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 13:10:13 -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: <51B23B0A.7040608@alum.mit.edu> Date: Fri, 7 Jun 2013 16:10:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B5B43BD-7681-4BE5-9857-94F307389C81@oracle.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <51B23B0A.7040608@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] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 20:10:22 -0000 I'm getting confused by this thread. History-Info (or Diversion) is only useful to know the original *called* = destination party, not *calling* source party. I.e., if the To-username gets changed by the PBX, Hist-info might tell = you what it used to be... if the req-uri matched the To, and the PBX = does Hist-Info, and all downstream devices pass it on, and if the final = UAS could decipher which Hist-info to look at, and if the stars aligned. But if the =46rom username got changed nothing will tell you what it = used to be. I think Brian was arguing the =46rom should be changed by = the PBX to be the new source of the new call, namely the PBX's main = number or the To-number being forwarded from - because otherwise it's = spoofing the =46rom for this "new" call - but I don't think it should = change the =46rom because I contend it's not spoofing, but just routing = the same call as a B2BUA. -hadriel On Jun 7, 2013, at 3:56 PM, Paul Kyzivat wrote: > On 6/7/13 2:23 PM, Alan Johnston wrote: >> I think that History-Info should be the solution going forward, >> certainly for SIP networks. >=20 > I expect that there will be a variety of "solutions". > We aren't obligated to mandate one. Its only necessary to ban = spoofing, and let people decide which alternative they want to use. >=20 > If H-I was deployed across the full range of equipment out there, I'd = expect that correct reporting of calling party would be very spotty. >=20 > Now that calling is typically cheap enough that most people don't = think about it, a simple solution to forwarding is 3xx, and to transfer = is basic REFER. Those will get the calling party right. (Except in cases = where you *want* the identify of the intermediary to be displayed. And = that is the easy case.) >=20 > Thanks, > Paul >=20 >> - Alan - >>=20 >>=20 >> On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian > > wrote: >>=20 >> A problem that has been noted is PBXs and other services that >> implement Call Forward and Follow-me by spoofing =46rom to be the >> original caller when they originate a call from the PBX to the >> ultimate destination. They do this so that the called party sees >> the original caller when they get the call. >>=20 >> If we outlaw spoofing, these services wouldn't be able to do that. >> They would have to use History or other headers to pass the >> original calling party number. >>=20 >> I believe that we can't continue to allow this kind of spoofing. >> There are other headers which are appropriate for use. >>=20 >> One of the arguments given is that in older systems such as POTS = or >> 2G/3G, there is no way to get caller ID to show data from the = other >> headers. I think we have to accept such limitations. Newer = systems >> would not have that problem of course. >>=20 >> While it may be unfortunate that something like forward or = follow-me >> doesn't work as well as it did, I think that it's the right = tradeoff. >>=20 >> Please note that there are another class of calling party number >> spoofing circumstances we CAN do something about. Suppose a = doctor >> wants to place a call on her mobile that appears to come from her >> office number. In that case the doctor can authorize the service >> that arranges that call. They can get the cert for the office >> number and authorize the service to place calls with that number = by >> giving them a cert for that authorization. This also works for, = as >> an example, a call center placing calls for an enterprise. >>=20 >> The difference is, of course, that the "spoofed" number is a = number >> delegated to the entity spoofing, rather than the forward/follow = me >> case where the spoofed number is the calling party and the entity >> spoofing is authorized by the called party. >>=20 >> Brian >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=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 Fri Jun 7 13:12: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 DCF0321F8FDC for ; Fri, 7 Jun 2013 13:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, 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 xmiuC-oPx+tO for ; Fri, 7 Jun 2013 13:11:58 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 11B8E21F8425 for ; Fri, 7 Jun 2013 13:11:58 -0700 (PDT) Received: (qmail 23222 invoked by uid 0); 7 Jun 2013 20:11:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 7 Jun 2013 20:11:35 -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=FJqxgMyHQnWuT2uv1OdZYoBaW4hDU8y1Kormzhpy2pE=; b=hirxV2PSVkUi1SPmZt9tTqR88DgGiKyRVO97nmVJeQyEUhE8TSpl8VhPUqQVsEyTh2I3CXOHk6bpeNyUAp6mYtdIb7Tu7zudOiYDUmfBpC2ULBmexANedoL0OtEGNJBu; Received: from [72.66.111.124] (port=54294 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ul30X-0001S0-6K; Fri, 07 Jun 2013 14:11:35 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> In-Reply-To: Date: Fri, 7 Jun 2013 16:11:29 -0400 Message-ID: <01f101ce63bb$3398d010$9aca7030$@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: AQKmG5pz++37aVJTb/vHdV/W8NbSYwHntOc5AjPy0gQBwyf+LAIYhVyTAaq0kXEB3hSFgAGpeArgAa0TiE6XBIh9IA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 20:12:07 -0000 > > > The cert is not carrying any notion of goodness whatsoever. It > > doesn't even have to identify the holder in any way. All it has to > > do is prove provenance for the number. > > > > That's a pretty good model. > > It's excellent in theory, but has not had a promising history on the open and wooly Internet. This isn't the open and wooly Internet. It's the telephone network, running in part on mostly private IP networks. Of course the solution works across the Internet, and many of us would be very pleased if there were lots of calls placed over the Internet with good end to end source identity. But the problem we're solving is more short term, in a more restricted environment. [RS> ] [RS> ] Brian is correct to point this out we are not right now talking about the wild and woolly Internet. TDM networks are dying but even the carrier based SIP/IMS networks are closed and heavily "managed" for lots of reasons, principally QoS and QoE. Brian _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Fri Jun 7 13:17: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 A566B21F869F for ; Fri, 7 Jun 2013 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, 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 g6aKcFgn+VzT for ; Fri, 7 Jun 2013 13:17:10 -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 0D00121F86D3 for ; Fri, 7 Jun 2013 13:17:09 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id lPf71l00327AodY5BYH91N; Fri, 07 Jun 2013 20:17:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id lYH91l0033ZTu2S3fYH9fV; Fri, 07 Jun 2013 20:17:09 +0000 Message-ID: <51B23FC3.6080002@alum.mit.edu> Date: Fri, 07 Jun 2013 16:17:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> In-Reply-To: <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> 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=1370636229; bh=dYSpNfX7spLr0SdOirX125LDlB8RQFE7X72S8sUDftk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rjCUUsVEZwI8Rx5hNYBmBLQUpkL/BVXDGqJNZXgGzChqf2r/gchSHhfK7XXKAyfOu vPhhu2h0RwvLt+dEjhIbeOLwLz+hb9NEmmxnVWP/iTz0iIFYQ2O5vfA5QcFgI7BLSK UlUDOyYhSbUrgVDAleiTR1F07mOOuUdtBV5pAhJXZVA+0iNAjiR/E+w5vUrU01omrO 8HNzJ2ET4b2Pc1AP9wcNQPRVlCTvmFAglYP/M0tlmJ+whT5vI/QpZ0V8Ui+vJbgAPZ uqpwOnIKfSxzXmlgUXKARLz8qB2JTmZVIis00KLu5t98sEaeyE2852EOad+m259Rgl U3CSt6LGk/EFQ== Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 20:17:22 -0000 On 6/7/13 3:53 PM, Henning Schulzrinne wrote: > > On Jun 7, 2013, at 3:38 PM, Paul Kyzivat wrote: > >> On 6/7/13 2:08 PM, Rosen, Brian wrote: >>> Yes, I'm asking if we can avoid using alternative headers. >>> >>> I'll start a thread on call forward/follow-me. >>> >>> I think presence of most prefixes would be pretty easy to deal with. I would not expect to see the PBX prefixes (9-1-202-555-1212), because the downstream entities couldn't route if they were there. >> >> Are we only talking about NANP, or numbers for anyplace? >> >> If you take a valid E.164 number, without the "+", and maybe with or without the country code, and potentially prefixed with arbitrary garbage, I'm pretty sure there is no way to uniquely identify the E.164 number. > > At least for countries with fixed-length numbers, such as the US, taking the last 10 digits would seem to work, if the number string is longer than that. That's why I asked if this was just for NANP. But even if we are only addressing concerns of the FCC, there are calls into the US from outside, and from inside to outside. So not all the numbers are going to be NANP numbers, and not all will be fixed length. Thanks, Paul From bernard.aboba@gmail.com Fri Jun 7 15:07: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 696AE21F8994 for ; Fri, 7 Jun 2013 15:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 gM2m5R1w+W45 for ; Fri, 7 Jun 2013 15:07:18 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE121F8551 for ; Fri, 7 Jun 2013 15:07:10 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so683293qeb.3 for ; Fri, 07 Jun 2013 15:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=InP9FwoVa12kcYLgyypL+JNlXaQ5IS1CGEEORcBXU/U=; b=dRJjHnXRaKno7x9o0lXwfYgmTg5hwE4WOSMWaY4BkJkVwM3J75zslvoTFLC4RI/r5n CkcI8QsTPRf5h8OawFDAgovTZ7BiumP+RRulfVAlsMfiDKuDutdj7OLmJKAI1UJpAoxv 6Y+Bjb/MoJu2r6VADiXpHnP9+JqtTUvvbl4yC8b/fKifxnmHIBIpcgnV7UR6gXjbWUbG kyhYFK7+Tcqy1y1YP0syIQtoaYvYAsrp2qHP9zQZdzW3i/i95Zgf3FEWK5T5Rm2xd3hV I8S1zIM1Mn2WD465EsqPa6sQvwq7XYmNwFw07URlyOiBMYrSyCmMbjl2ZJrme8ww8AaB +Siw== X-Received: by 10.224.109.71 with SMTP id i7mr5118331qap.80.1370642829837; Fri, 07 Jun 2013 15:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.74.34 with HTTP; Fri, 7 Jun 2013 15:06:49 -0700 (PDT) In-Reply-To: <0B5B43BD-7681-4BE5-9857-94F307389C81@oracle.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <51B23B0A.7040608@alum.mit.edu> <0B5B43BD-7681-4BE5-9857-94F307389C81@oracle.com> From: Bernard Aboba Date: Fri, 7 Jun 2013 15:06:49 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 22:07:23 -0000 Hadriel said: "But if the From username got changed nothing will tell you what it used to be. I think Brian was arguing the From should be changed by the PBX to be the new source of the new call, namely the PBX's main number or the To-number being forwarded from - because otherwise it's spoofing the From for this "new" call - but I don't think it should change the From because I contend it's not spoofing, but just routing the same call as a B2BUA." [BA] I think what is being advocated is not to break the original signature, however it is done. So if the signature is over the To: and From: field but not the Request-URI, then the PBX could re-target without having to recompute (or invalidate) the signature. Re-targeting without changing the "From:" would not be considered "spoofing". From bernard.aboba@gmail.com Fri Jun 7 15:12: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 9F59F21F88AC for ; Fri, 7 Jun 2013 15:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 Y3eZHwz69Z0P for ; Fri, 7 Jun 2013 15:12:19 -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 6C60121F88EA for ; Fri, 7 Jun 2013 15:12:19 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so3047302qea.21 for ; Fri, 07 Jun 2013 15:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z6bbg9V6npM6EFXNnWnhoLaoqsT6OROu1Erk26bsfew=; b=0nEPWW9aGBMhC2a/CZGOM1O/ozaKBbZRHHPqt0XuMdbcHTLsy+fMpZQ5oM8n/gJT2W yLqGw6bec4G9DMCkZiz4y1Tnlt8MwV5XVn8IC3MbHzHc/+qlCFojdgyB9vZc3iQJFzYG 2amMNdVpxZ3WBCF7nDnxdJ/xMhRk4Lh5HV42LRltAGeHUfeRsxWio6tqJqptjlbVZzbd TjEOsGtFGEpCWeFhstJ+Nrb050e9X9Whmd34vJaUhkhCfZ9NlZ47nwGWxMpuDNdak/2L BNBUNZZjEkm10tcG4KBcgRwY5J4FFk9gxD+r1YGxmcTsqQG5WoQE9B0qbrdUf3Kvt9Hn kImw== X-Received: by 10.224.42.195 with SMTP id t3mr5166572qae.44.1370643137965; Fri, 07 Jun 2013 15:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.74.34 with HTTP; Fri, 7 Jun 2013 15:11:56 -0700 (PDT) In-Reply-To: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> From: Bernard Aboba Date: Fri, 7 Jun 2013 15:11:56 -0700 Message-ID: To: Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 22:12:24 -0000 On Fri, Jun 7, 2013 at 11:40 AM, Henning Schulzrinne wrote: "On forwarding, it would seem that, in many cases, the validation is done *before* the forwarding happens. For example, the typical follow-me on a PBX is done by my (trusted) PBX, and it would do the validation on the incoming call. " [BA] Right. Presumably if the validation fails, the forwarding would not occur. But the question is whether the PBX will handle forwarding in a way that would invalidate the signature and make it seem like the forwarded call is spoofed when it is not. From stephen.farrell@cs.tcd.ie Fri Jun 7 15:21: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 063F021F99C9 for ; Fri, 7 Jun 2013 15:21:53 -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 iKI8mekoRB-S for ; Fri, 7 Jun 2013 15:21:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 716FA21F99C2 for ; Fri, 7 Jun 2013 15:21:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A378BEBB; Fri, 7 Jun 2013 23:21:03 +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 G1P7E1D7lUcL; Fri, 7 Jun 2013 23:21:02 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.20.254]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5CE2FBEB6; Fri, 7 Jun 2013 23:21:02 +0100 (IST) Message-ID: <51B25CC4.6040902@cs.tcd.ie> Date: Fri, 07 Jun 2013 23:20:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> In-Reply-To: <51B23FC3.6080002@alum.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 22:21:53 -0000 On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >> >> At least for countries with fixed-length numbers, such as the US, >> taking the last 10 digits would seem to work, if the number string is >> longer than that. > > That's why I asked if this was just for NANP. > But even if we are only addressing concerns of the FCC, there are calls > into the US from outside, and from inside to outside. So not all the > numbers are going to be NANP numbers, and not all will be fixed length. IMO a solution that did not allow signatures over numbers from any country to be validated reliably would simply be broken. If I were still on the IESG when that came up, it'd be a guaranteed discuss ballot from me. And not one that'd go away until the problem was properly fixed. There may well be issues to do with canonicalisation and there may be discussion needed as to how that is split between signer and verifier. But a country agnostic solution is definitely required at the sign/verify/bind-to-cert level. S. From rlb@ipv.sx Fri Jun 7 15: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 5732321F99B6 for ; Fri, 7 Jun 2013 15:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1v4di1IOQibS for ; Fri, 7 Jun 2013 15:38:19 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2545E21F995F for ; Fri, 7 Jun 2013 15:38:18 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id g12so3880629oah.12 for ; Fri, 07 Jun 2013 15:38:18 -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=2BokKpPXPvvM8v4uLAmc3Gk4MBYF43UcOOueJZTV16E=; b=YmRNbvttArWhKbSEv5SLX/ygMMBvDPnTE9pJss3H+/QyvxcTnQN7/8yxHObdH+colC zMsEJYxguMlI/gYG+E414cP8+pq2589jPdpGinn3i/vbqhXtlAKExB70LXSUxVpkkKfZ FJS6ZU+K4MxoivaInwArMf48FL9Whm21B+O/EAi3uxN2s1DIAh5aOEMdIl3K3MEp4UGM 91PxJe0Gm7zY4CIsT9Aiq9+/Z/ZjXx/8eVUggKESIK6jLUL+3Q3278EH4lM5uwo02YG0 wdUbjHrtT8hC8EJrg0A1RlAA0lyNHldKxlz+xJZE1dpDsP3/rsKlIUe5W/6kyk9QWQo/ TDkA== MIME-Version: 1.0 X-Received: by 10.60.39.165 with SMTP id q5mr496586oek.109.1370644698239; Fri, 07 Jun 2013 15:38:18 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Fri, 7 Jun 2013 15:38:18 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <51B25CC4.6040902@cs.tcd.ie> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> Date: Fri, 7 Jun 2013 18:38:18 -0400 Message-ID: From: Richard Barnes To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e013cbeec5a274f04de9816e1 X-Gm-Message-State: ALoCoQmQUA3R/Q5SSCI6D4x2d2FfeB4oztiU+IMVI1E53SnTbUcUdy+98BDT1q7CyAf81kzEJ/+x Cc: stir@ietf.org, Paul Kyzivat , Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 22:38:23 -0000 --089e013cbeec5a274f04de9816e1 Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Jun 7, 2013 at 6:20 PM, Stephen Farrell wrote: > > > On 06/07/2013 09:17 PM, Paul Kyzivat wrote: > >> > >> At least for countries with fixed-length numbers, such as the US, > >> taking the last 10 digits would seem to work, if the number string is > >> longer than that. > > > > That's why I asked if this was just for NANP. > > But even if we are only addressing concerns of the FCC, there are calls > > into the US from outside, and from inside to outside. So not all the > > numbers are going to be NANP numbers, and not all will be fixed length. > > IMO a solution that did not allow signatures over numbers from any > country to be validated reliably would simply be broken. If I were > still on the IESG when that came up, it'd be a guaranteed discuss > ballot from me. And not one that'd go away until the problem was > properly fixed. > > There may well be issues to do with canonicalisation and there may > be discussion needed as to how that is split between signer and > verifier. But a country agnostic solution is definitely required > at the sign/verify/bind-to-cert level. > > S. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --089e013cbeec5a274f04de9816e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Fri, Jun 7, 2013 at 6:20 PM, Stephen Farrell <steph= en.farrell@cs.tcd.ie> wrote:


On 06/07/2013 09:17 PM, Paul Kyzivat wrote:
>>
>> At least for countries with fixed-length numbers, such as the US,<= br> >> taking the last 10 digits would seem to work, if the number string= is
>> longer than that.
>
> That's why I asked if this was just for NANP.
> But even if we are only addressing concerns of the FCC, there are call= s
> into the US from outside, and from inside to outside. So not all the > numbers are going to be NANP numbers, and not all will be fixed length= .

IMO a solution that did not allow signatures over numbers from any country to be validated reliably would simply be broken. If I were
still on the IESG when that came up, it'd be a guaranteed discuss
ballot from me. And not one that'd go away until the problem was
properly fixed.

There may well be issues to do with canonicalisation and there may
be discussion needed as to how that is split between signer and
verifier. But a country agnostic solution is definitely required
at the sign/verify/bind-to-cert level.

S.
_____________________= __________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--089e013cbeec5a274f04de9816e1-- From richard@shockey.us Fri Jun 7 15:51: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 D6D1D21F8930 for ; Fri, 7 Jun 2013 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, 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 ZEhBGAx0NcpR for ; Fri, 7 Jun 2013 15:51:54 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 01FC021F99DE for ; Fri, 7 Jun 2013 15:51:53 -0700 (PDT) Received: (qmail 8522 invoked by uid 0); 7 Jun 2013 22:51:32 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 7 Jun 2013 22:51:32 -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=IuK6SWifsiBLCpykW6m+jNjPlYtsPVI/hCWqcwHvInc=; b=BfsIG9F5lfan6H/0r7wjhc+UolDdi/bLSSV1kbRuem1pXpmD2vLPdLEN9kf/STisBeN1cADQL1yB7oSw4EnrXBNr9pE3LoedSjK0QssRlZsL2oMRxMxPvyeHWiAQjP8k; Received: from [72.66.111.124] (port=57222 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ul5VL-0004rI-T2; Fri, 07 Jun 2013 16:51:32 -0600 From: "Richard Shockey" To: "'Stephen Farrell'" , "'Paul Kyzivat'" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> In-Reply-To: <51B25CC4.6040902@cs.tcd.ie> Date: Fri, 7 Jun 2013 18:51:27 -0400 Message-ID: <023a01ce63d1$8c4f3940$a4edabc0$@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: AQKmG5pz++37aVJTb/vHdV/W8NbSYwFcQ9TLAgup6o8CYDH+vQHX9ZTaAnP9FTQCC5CM+5cabQJQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Henning Schulzrinne' Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 22:51:59 -0000 There are only a limited number of countries that still support variable length dial plans. Germany is the worst case. There are variations in localized dialing schemes but the solution for that was always convert the local number to the full E.164 before look ups. We went round and round on this in ENUM. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, June 07, 2013 6:21 PM To: Paul Kyzivat Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >> >> At least for countries with fixed-length numbers, such as the US, >> taking the last 10 digits would seem to work, if the number string is >> longer than that. > > That's why I asked if this was just for NANP. > But even if we are only addressing concerns of the FCC, there are > calls into the US from outside, and from inside to outside. So not all > the numbers are going to be NANP numbers, and not all will be fixed length. IMO a solution that did not allow signatures over numbers from any country to be validated reliably would simply be broken. If I were still on the IESG when that came up, it'd be a guaranteed discuss ballot from me. And not one that'd go away until the problem was properly fixed. There may well be issues to do with canonicalisation and there may be discussion needed as to how that is split between signer and verifier. But a country agnostic solution is definitely required at the sign/verify/bind-to-cert level. S. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Fri Jun 7 16:05: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 03B2021F961B for ; Fri, 7 Jun 2013 16:05:08 -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 CS5JxTEIZuJ4 for ; Fri, 7 Jun 2013 16:05:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F042A21F84D8 for ; Fri, 7 Jun 2013 16:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78FD5BEB2; Sat, 8 Jun 2013 00:04:40 +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 A7QOWHVkrgpw; Sat, 8 Jun 2013 00:04:39 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.20.254]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B853BE73; Sat, 8 Jun 2013 00:04:37 +0100 (IST) Message-ID: <51B266FB.60105@cs.tcd.ie> Date: Sat, 08 Jun 2013 00:04:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Shockey References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> In-Reply-To: <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, 'Paul Kyzivat' , 'Henning Schulzrinne' Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 23:05:08 -0000 On 06/07/2013 11:51 PM, Richard Shockey wrote: > There are only a limited number of countries that still support variable > length dial plans. Germany is the worst case. > > There are variations in localized dialing schemes but the solution for that > was always convert the local number to the full E.164 before look ups. If that's the answer for both caller and callee numbers and it works then that sounds ok. I'd not be surprised if there were wrinkles, and that might be ok...depending. It'd not be ok if the wrinkles overwhelmingly and significantly affected non-NANP numbers for example. > We went round and round on this in ENUM. No need to do it again then maybe:-) Or perhaps this context is different if one needs to sign/verify both numbers rather than just looking one up in the DNS. But the country-agnostic requirement is I think clear enough, particularly at this pre-chartering stage, i.e. I don't think there's a need to delve into possible solutions(s) right now. S. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, June 07, 2013 6:21 PM > To: Paul Kyzivat > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >>> >>> At least for countries with fixed-length numbers, such as the US, >>> taking the last 10 digits would seem to work, if the number string is >>> longer than that. >> >> That's why I asked if this was just for NANP. >> But even if we are only addressing concerns of the FCC, there are >> calls into the US from outside, and from inside to outside. So not all >> the numbers are going to be NANP numbers, and not all will be fixed > length. > > IMO a solution that did not allow signatures over numbers from any country > to be validated reliably would simply be broken. If I were still on the IESG > when that came up, it'd be a guaranteed discuss ballot from me. And not one > that'd go away until the problem was properly fixed. > > There may well be issues to do with canonicalisation and there may be > discussion needed as to how that is split between signer and verifier. But a > country agnostic solution is definitely required at the > sign/verify/bind-to-cert level. > > S. > _______________________________________________ > 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 Fri Jun 7 16:11: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 424BA21F99CE for ; Fri, 7 Jun 2013 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, 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 WCvZ2HMwJtsq for ; Fri, 7 Jun 2013 16:11:04 -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 6DC6E21F99C4 for ; Fri, 7 Jun 2013 16:11:04 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id lb6Q1l00D0vyq2s51bB3om; Fri, 07 Jun 2013 23:11:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id lbB31l00P3ZTu2S3RbB3KT; Fri, 07 Jun 2013 23:11:03 +0000 Message-ID: <51B26886.8020000@alum.mit.edu> Date: Fri, 07 Jun 2013 19:11:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> In-Reply-To: <023a01ce63d1$8c4f3940$a4edabc0$@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=1370646663; bh=NFEoM4VackAyHkwkfkeWiGQVv9cc75t01VSEAFi+o78=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CSG7Xz9oF0pbHmCGv7uiDeYRkCwzsTi7uHue9r+KX2w7aGnUpeTBbSYQ7ir9XiEIk c34Pbl47nbsr6XuFkPgUzqmTFoYwrcbo02QRaszeeGDTww1PmEMLDeP2yWuKQLFVrl 4jEuc11FgMHXXFapvQGQGu0N9QSmelJdV4yTqRyLhAZWk1jIG6iuExN5BUgcHPmf8s kwGnfoJe3uWQ7LjvkCAvof63IB50Ri/0JEQGFak61WzzKIQ1wP9hgoE634fiFgG9GX qeREgZDznCT0aiN44GroOSnUm5a2OG1K0bM0YOx872CiT4KlvifK8EE+MRfvPwjWQq /oViglwa8ZvvA== Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 23:11:09 -0000 The sensible thing would be to expect the numbers to be "pure" E.164 (with the +), before signing. But that might take some doing. Thanks, Paul On 6/7/13 6:51 PM, Richard Shockey wrote: > There are only a limited number of countries that still support variable > length dial plans. Germany is the worst case. > > There are variations in localized dialing schemes but the solution for that > was always convert the local number to the full E.164 before look ups. > > We went round and round on this in ENUM. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Friday, June 07, 2013 6:21 PM > To: Paul Kyzivat > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >>> >>> At least for countries with fixed-length numbers, such as the US, >>> taking the last 10 digits would seem to work, if the number string is >>> longer than that. >> >> That's why I asked if this was just for NANP. >> But even if we are only addressing concerns of the FCC, there are >> calls into the US from outside, and from inside to outside. So not all >> the numbers are going to be NANP numbers, and not all will be fixed > length. > > IMO a solution that did not allow signatures over numbers from any country > to be validated reliably would simply be broken. If I were still on the IESG > when that came up, it'd be a guaranteed discuss ballot from me. And not one > that'd go away until the problem was properly fixed. > > There may well be issues to do with canonicalisation and there may be > discussion needed as to how that is split between signer and verifier. But a > country agnostic solution is definitely required at the > sign/verify/bind-to-cert level. > > S. > _______________________________________________ > 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 hgs@cs.columbia.edu Fri Jun 7 19:18: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 13BD921F9A13 for ; Fri, 7 Jun 2013 19:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 pQI9Uqkh+m8H for ; Fri, 7 Jun 2013 19:18:38 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBD21F9A15 for ; Fri, 7 Jun 2013 19:18:37 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r582IWpS023911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 22:18:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <42E4DFC6-1DAF-4342-9CB3-2EFDF728C7C1@neustar.biz> Date: Fri, 7 Jun 2013 22:18:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> <42E4DFC6-1DAF-4342-9CB3-2EFDF728C7C1@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 02:18:44 -0000 I'm trying to identify common cases, while still dealing with the = others, possibly in more complicated ways.=20 (1) We seem to agree that canonicalization should be possible, = particularly from and to the edges of carrier networks, even beyond the = +1 scope. I believe this is true since it would otherwise be nearly = impossible to populate SS7 fields correctly, and I suspect that the = tolerance of switches for SS7 field variations is a bit less than for = SIP SBCs. In particular, since originating numbers are often used for = intercarrier compensation, there are clear business reasons not to have = too many variations that can't be understood by carriers that exchange = traffic. I haven't looked at SS7 traces to see whether this is true in = practice, but I suspect there are people on this list who have. (2) For the forwarding/follow-me case, there seem to be two cases: (a) The PBX creates a new call, but still uses the original From. In = that case, the PBX could use its generic signature. The recipient very = likely is a customer/employee of the PBX owner/operator, so it can = easily recognize that this is "home" calling. (b) The PBX can pass on the signature if the To is maintained and the = call is routed based on the request-URI. For (b), we have to decide whether To should be part of the signature. = If not, the signature will survive forwarding, but this will obviously = make abuse by replay much easier, at least for a few seconds until the = Date fails the staleness test. I'm personally not very worried about = replay, given the practical difficulties of intercepting "good" calls, = if we ignore the NSA for the moment, but that requires more discussion. Thus, one possibility is that, long-term, number-based certs are used = for the most common "interdomain" calling cases, edge-to-edge, and "good = guy" certs for the special cases where number certs are difficult to = obtain. Henning On Jun 7, 2013, at 3:01 PM, Rosen, Brian wrote: > Okay, but what is "rogue"? >=20 > Suppose they do as Hadriel suggests, and accept a PRI without checking = calling party number to see it's one of theirs. Is that "rogue"? > As you say, some of these calls skate a line on whether they are legal = or not. But even if they are legal, then the caller still could have a = reasonable expectation of the ID being accurate. >=20 > If you keep to the notion that we're not trying to designate good guys = but instead trying to determine if the calling party number is accurate, = then using the cert-follows-number-delegation makes things uniformly = straightforward. >=20 > Brian >=20 From hgs@cs.columbia.edu Fri Jun 7 19:23: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 07F9A21F9990 for ; Fri, 7 Jun 2013 19:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 CTXsUcBKMAkH for ; Fri, 7 Jun 2013 19:23:33 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id E25FF21F998D for ; Fri, 7 Jun 2013 19:23:32 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r582NVIx009393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 22:23:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> Date: Fri, 7 Jun 2013 22:23:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 02:23:45 -0000 On Jun 7, 2013, at 2:17 PM, Rosen, Brian wrote: >=20 > Please note that there are another class of calling party number = spoofing circumstances we CAN do something about. Suppose a doctor = wants to place a call on her mobile that appears to come from her office = number. In that case the doctor can authorize the service that arranges = that call. They can get the cert for the office number and authorize = the service to place calls with that number by giving them a cert for = that authorization. This also works for, as an example, a call center = placing calls for an enterprise. That's probably something we might want to flesh out a bit. My very = rough vision in the central database case would be something like the = following: (1) Owner [doctors' office] says: "Please mint a cert that entitles = Doctor Smith [public key attached] to use our number 555 1234." [signed = by assignee] (2) Database returns cert, which is handed to doctor. (4) Doctor uses cert just like any other. From rlb@ipv.sx Fri Jun 7 20: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 B5B8521F9473 for ; Fri, 7 Jun 2013 20:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cyE7D7hS1ciF for ; Fri, 7 Jun 2013 20:12:51 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55A21F9424 for ; Fri, 7 Jun 2013 20:12:51 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so7488290obc.27 for ; Fri, 07 Jun 2013 20:12:50 -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=6vNjTlccLImy/JiG8MLvCOmniORxtf5DvgfB7Xm01Uo=; b=jjJgbuiX5uNnoYWwKNE/wSL0q5PH2P52H1RupJxBPdGuCX/HEDT84+6P6fjJuQKk1i VcicLWJTp9hiL31JTLeCSRuTAvTlyevK9SwXzU6MnulOiE6TfUP/pwrEFmYAhzMsNPG/ wh5fUFuWAEK7ropx+5bhTntaEMcxtGBLL9VPbaDrsABRsrjAK4o7QlJHcPZNJs31kyND dvhTWTLA7DU3l16hoSCKWPCwAw0WUylwRbz8XORarJtjd+bxxggdiBNsxIk9GYMVA0dK AhshcEDX26nUD0/xFa/+NP55RD5DKo6KGVQ7BFB33OHDTkbDmnAm+LtMBG3TZVEVq/+l Xokg== MIME-Version: 1.0 X-Received: by 10.60.43.232 with SMTP id z8mr970356oel.138.1370661170546; Fri, 07 Jun 2013 20:12:50 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Fri, 7 Jun 2013 20:12:50 -0700 (PDT) X-Originating-IP: [128.89.255.252] In-Reply-To: <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> Date: Fri, 7 Jun 2013 23:12:50 -0400 Message-ID: From: Richard Barnes To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=001a113311fc2ee96604de9bec24 X-Gm-Message-State: ALoCoQlftzNLwbdeGzj592t34of/6NSSqAqFmiQInSxuVXu3e+ALM9WI73hjU5LsuGWJg2eIo97q Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 03:12:56 -0000 --001a113311fc2ee96604de9bec24 Content-Type: text/plain; charset=ISO-8859-1 The RPKI has a protocol for this, known colloquially as the "up/down" protocol. Certificate request: On Fri, Jun 7, 2013 at 10:23 PM, Henning Schulzrinne wrote: > On Jun 7, 2013, at 2:17 PM, Rosen, Brian wrote: > > > > Please note that there are another class of calling party number > spoofing circumstances we CAN do something about. Suppose a doctor wants > to place a call on her mobile that appears to come from her office number. > In that case the doctor can authorize the service that arranges that call. > They can get the cert for the office number and authorize the service to > place calls with that number by giving them a cert for that authorization. > This also works for, as an example, a call center placing calls for an > enterprise. > > > That's probably something we might want to flesh out a bit. My very rough > vision in the central database case would be something like the following: > > (1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor > Smith [public key attached] to use our number 555 1234." [signed by > assignee] > > (2) Database returns cert, which is handed to doctor. > > (4) Doctor uses cert just like any other. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a113311fc2ee96604de9bec24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The RPKI has a protocol for this, known colloquially = as the "up/down" protocol.
=

Certificate request:


On Fri, Jun 7, 2013 at 10:23 PM, Henning Schulzrinne <= hgs@cs.columbia.ed= u> wrote:
On Jun 7, 2013, at 2:17 PM, Rosen, Brian wrote:
>
> Please note that there are another class of calling party number spoof= ing circumstances we CAN do something about. =A0Suppose a doctor wants to p= lace a call on her mobile that appears to come from her office number. =A0I= n that case the doctor can authorize the service that arranges that call. = =A0They can get the cert for the office number and authorize the service to= place calls with that number by giving them a cert for that authorization.= =A0This also works for, as an example, a call center placing calls for an = enterprise.


That's probably something we might want to flesh out a bit. My very rou= gh vision in the central database case would be something like the followin= g:

(1) Owner [doctors' office] says: "Please mint a cert that entitle= s Doctor Smith [public key attached] to use our number 555 1234." [sig= ned by assignee]

(2) Database returns cert, which is handed to doctor.

(4) Doctor uses cert just like any other.

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

--001a113311fc2ee96604de9bec24-- From richard@shockey.us Sat Jun 8 08:27: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 CA4ED21F8605 for ; Sat, 8 Jun 2013 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.207, 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 LW0SVu6Z5Ngm for ; Sat, 8 Jun 2013 08:27:21 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id E63DE21F85C3 for ; Sat, 8 Jun 2013 08:27:20 -0700 (PDT) Received: (qmail 26698 invoked by uid 0); 8 Jun 2013 15:26:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 8 Jun 2013 15:26:56 -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=aG/G44DKxAg/ERFlS4cOqRl+N7+eVgnp4Zm0E/JiT2I=; b=CcxxPjBdlhgpbYXddz6KbUMHo24JUvizjUpGkxtOfxlQnfmesfnUfiLkkyIcg3pe+kNQMFVz4Bshq2nPzIP7y9zDVeWM0eRlJeLZaMmEZJbhT6Mn+wB9EvaxnzvLBnP5; Received: from [72.66.111.124] (port=49951 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UlL2d-0003Ot-Qv for stir@ietf.org; Sat, 08 Jun 2013 09:26:56 -0600 From: "Richard Shockey" To: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> <51B26886.8020000@alum.mit.edu> In-Reply-To: <51B26886.8020000@alum.mit.edu> Date: Sat, 8 Jun 2013 11:26:52 -0400 Message-ID: <005801ce645c$9adebae0$d09c30a0$@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: AQKmG5pz++37aVJTb/vHdV/W8NbSYwFcQ9TLAgup6o8CYDH+vQHX9ZTaAnP9FTQCC5CM+wG62xlgAfkGu+qW/dpLcA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 15:27:25 -0000 Correct. There are some interesting tangential issues here that push that process forward. I actually think the process might be easier that we might imagine. If you look at the STIR problem statement in the larger context of PSTN Transition this is actually the perfect time to consider this work. It has been clear to many of us for some time that that the carriers and the NRA's were going to have to take a long look at the structure of National Numbering Databases in general. Ultimately those databases (and they are not public) could contain URI data in order to facilitate all SIP Interconnection. There is a LOT of that going on right now. Transition is easier when you have national CDB structured for LNP like the NPAC or in the case of the Netherlands COIN, Ireland, Sweden, Brazil, India, Pakistan etc. I think you could make that argument that there is sufficient national administrative expertise here facilitate the process going forward since the lines of delegation are well understood. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, June 07, 2013 7:11 PM To: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? The sensible thing would be to expect the numbers to be "pure" E.164 (with the +), before signing. But that might take some doing. Thanks, Paul On 6/7/13 6:51 PM, Richard Shockey wrote: > There are only a limited number of countries that still support > variable length dial plans. Germany is the worst case. > > There are variations in localized dialing schemes but the solution for > that was always convert the local number to the full E.164 before look ups. > > We went round and round on this in ENUM. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Friday, June 07, 2013 6:21 PM > To: Paul Kyzivat > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >>> >>> At least for countries with fixed-length numbers, such as the US, >>> taking the last 10 digits would seem to work, if the number string >>> is longer than that. >> >> That's why I asked if this was just for NANP. >> But even if we are only addressing concerns of the FCC, there are >> calls into the US from outside, and from inside to outside. So not >> all the numbers are going to be NANP numbers, and not all will be >> fixed > length. > > IMO a solution that did not allow signatures over numbers from any > country to be validated reliably would simply be broken. If I were > still on the IESG when that came up, it'd be a guaranteed discuss > ballot from me. And not one that'd go away until the problem was properly fixed. > > There may well be issues to do with canonicalisation and there may be > discussion needed as to how that is split between signer and verifier. > But a country agnostic solution is definitely required at the > sign/verify/bind-to-cert level. > > S. > _______________________________________________ > 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 Sat Jun 8 10:41: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 38BA421F9248 for ; Sat, 8 Jun 2013 10:41:51 -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=[AWL=-0.000, BAYES_00=-2.599, 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 Ckyq9R8b7IZq for ; Sat, 8 Jun 2013 10:41:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A855921F921F for ; Sat, 8 Jun 2013 10:41:44 -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 r58HfaNO007173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jun 2013 17:41:37 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 r58HfZhb018299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 17:41:36 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 r58HfZwM000325; Sat, 8 Jun 2013 17:41:35 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-156-6.vpn.oracle.com (/10.154.156.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Jun 2013 10:41:34 -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, 8 Jun 2013 13:41:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05EABBC8-6318-413D-8B22-2CA735826450@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> <42E4DFC6-1DAF-4342-9CB3-2EFDF728C7C1@neustar.biz> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Rosen, Brian" , stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 17:41:51 -0000 On Jun 7, 2013, at 10:18 PM, Henning Schulzrinne = wrote: > (1) We seem to agree that canonicalization should be possible, = particularly from and to the edges of carrier networks, even beyond the = +1 scope. I believe this is true since it would otherwise be nearly = impossible to populate SS7 fields correctly, and I suspect that the = tolerance of switches for SS7 field variations is a bit less than for = SIP SBCs. In particular, since originating numbers are often used for = intercarrier compensation, there are clear business reasons not to have = too many variations that can't be understood by carriers that exchange = traffic. I haven't looked at SS7 traces to see whether this is true in = practice, but I suspect there are people on this list who have. Yes, I think I misunderstood Brian and your questions about = canonicalization. I thought you meant can we define a canonical format = of the To/=46rom usernames that everyone must start using on-the-wire = for this new mechanism, so we can sign the To/=46rom URIs. But really = what you meant was the To/=46rom can change constantly on-the-wire, so = long as a signer/verifier can programmatically determine some canonical = form from the non-canonical one received on-the-wire. So you don't care = what the literal strings are on-the-wire, right? > (2) For the forwarding/follow-me case, there seem to be two cases: >=20 > (a) The PBX creates a new call, but still uses the original From. In = that case, the PBX could use its generic signature. The recipient very = likely is a customer/employee of the PBX owner/operator, so it can = easily recognize that this is "home" calling. I expect it to be rare for the endpoint phones to do the verification - = it would be the terminating service provider, who won't know the PBX is = a legitimate signer for someone else's phone number. With the sip asserter identity draft, the PBX can create a new SIP call = but use the same signature it received for the same original =46rom = (well, it's really a P-Asserted-Identity instead of From) > (b) The PBX can pass on the signature if the To is maintained and the = call is routed based on the request-URI. > For (b), we have to decide whether To should be part of the signature. = If not, the signature will survive forwarding, but this will obviously = make abuse by replay much easier, at least for a few seconds until the = Date fails the staleness test. I'm personally not very worried about = replay, given the practical difficulties of intercepting "good" calls, = if we ignore the NSA for the moment, but that requires more discussion. That's one of the reasons the sip asserter-identity draft put the = original To in a new separate header and signed that instead. The PBX can forward the call and change the To, and the signature = doesn't break but still has replay protection. -hadriel From hgs@cs.columbia.edu Sat Jun 8 11:01: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 8B46121F92B8 for ; Sat, 8 Jun 2013 11:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 FkE0Yn9cOpRU for ; Sat, 8 Jun 2013 11:01:32 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9579321F92B7 for ; Sat, 8 Jun 2013 11:01:32 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r58I1RPI022069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2013 14:01:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <05EABBC8-6318-413D-8B22-2CA735826450@oracle.com> Date: Sat, 8 Jun 2013 14:01:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB9FCA7-09F2-4B73-8D03-84ECEB518399@cs.columbia.edu> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <55CA4405-FD9B-4D7A-9A3D-F77B6E60D69D@cs.columbia.edu> <42E4DFC6-1DAF-4342-9CB3-2EFDF728C7C1@neustar.biz> <05EABBC8-6318-413D-8B22-2CA735826450@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "Rosen, Brian" , stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 18:01:38 -0000 Inline. On Jun 8, 2013, at 1:41 PM, Hadriel Kaplan wrote: >=20 > On Jun 7, 2013, at 10:18 PM, Henning Schulzrinne = wrote: >=20 >> (1) We seem to agree that canonicalization should be possible, = particularly from and to the edges of carrier networks, even beyond the = +1 scope. I believe this is true since it would otherwise be nearly = impossible to populate SS7 fields correctly, and I suspect that the = tolerance of switches for SS7 field variations is a bit less than for = SIP SBCs. In particular, since originating numbers are often used for = intercarrier compensation, there are clear business reasons not to have = too many variations that can't be understood by carriers that exchange = traffic. I haven't looked at SS7 traces to see whether this is true in = practice, but I suspect there are people on this list who have. >=20 > Yes, I think I misunderstood Brian and your questions about = canonicalization. I thought you meant can we define a canonical format = of the To/=46rom usernames that everyone must start using on-the-wire = for this new mechanism, so we can sign the To/=46rom URIs. But really = what you meant was the To/=46rom can change constantly on-the-wire, so = long as a signer/verifier can programmatically determine some canonical = form from the non-canonical one received on-the-wire. So you don't care = what the literal strings are on-the-wire, right? Indeed. I only care about two operations: (1) The caller edge node can extract E.164 numbers from the =46rom and = To, convert it into a tel: URI and include it in the signature. [The = conversion to a tel URI isn't really necessary, but might be a good way = to have a single logical representation for both the tel and non-tel = cases.] (2) The callee edge node can do the same and thus compare the signature. >=20 >=20 >> (2) For the forwarding/follow-me case, there seem to be two cases: >>=20 >> (a) The PBX creates a new call, but still uses the original From. In = that case, the PBX could use its generic signature. The recipient very = likely is a customer/employee of the PBX owner/operator, so it can = easily recognize that this is "home" calling. >=20 > I expect it to be rare for the endpoint phones to do the verification = - it would be the terminating service provider, who won't know the PBX = is a legitimate signer for someone else's phone number. > With the sip asserter identity draft, the PBX can create a new SIP = call but use the same signature it received for the same original =46rom = (well, it's really a P-Asserted-Identity instead of From) >=20 >=20 >> (b) The PBX can pass on the signature if the To is maintained and the = call is routed based on the request-URI. >> For (b), we have to decide whether To should be part of the = signature. If not, the signature will survive forwarding, but this will = obviously make abuse by replay much easier, at least for a few seconds = until the Date fails the staleness test. I'm personally not very worried = about replay, given the practical difficulties of intercepting "good" = calls, if we ignore the NSA for the moment, but that requires more = discussion. >=20 > That's one of the reasons the sip asserter-identity draft put the = original To in a new separate header and signed that instead. > The PBX can forward the call and change the To, and the signature = doesn't break but still has replay protection. The question is whether History-Info can do the same thing. To the = extent possible, it would seem to be nice to have a uniform mechanism = that can handle both the direct call and redirected call case, rather = than two completely separate ones. >=20 > -hadriel >=20 >=20 From michael.hammer@yaanatech.com Sat Jun 8 11:16: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 6E0D821F935A for ; Sat, 8 Jun 2013 11:16:20 -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 6394PB12Zewl for ; Sat, 8 Jun 2013 11:16:16 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4443621F9347 for ; Sat, 8 Jun 2013 11:16:16 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Sat, 8 Jun 2013 11:16:15 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY9RMJLmz47dNdkODXUFPcnbcSZksIDlg Date: Sat, 8 Jun 2013 18:16:14 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DAA8B@ex2k10mb2.corp.yaanatech.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> <51B26886.8020000@alum.mit.edu> In-Reply-To: <51B26886.8020000@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.35] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01CE6452.BB2A71E0" MIME-Version: 1.0 Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 18:16:20 -0000 ------=_NextPart_000_000D_01CE6452.BB2A71E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If we were to define new headers to be strictly E.164 numbers that must not be modified no matter how many networks you hop through, And those are the ones that get signed, then you would not even need the "+" prefix. The current headers are too over-loaded with usages at this point to be much help here. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, June 07, 2013 7:11 PM To: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? The sensible thing would be to expect the numbers to be "pure" E.164 (with the +), before signing. But that might take some doing. Thanks, Paul On 6/7/13 6:51 PM, Richard Shockey wrote: > There are only a limited number of countries that still support > variable length dial plans. Germany is the worst case. > > There are variations in localized dialing schemes but the solution for > that was always convert the local number to the full E.164 before look ups. > > We went round and round on this in ENUM. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Friday, June 07, 2013 6:21 PM > To: Paul Kyzivat > Cc: stir@ietf.org; Henning Schulzrinne > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >>> >>> At least for countries with fixed-length numbers, such as the US, >>> taking the last 10 digits would seem to work, if the number string >>> is longer than that. >> >> That's why I asked if this was just for NANP. >> But even if we are only addressing concerns of the FCC, there are >> calls into the US from outside, and from inside to outside. So not >> all the numbers are going to be NANP numbers, and not all will be >> fixed > length. > > IMO a solution that did not allow signatures over numbers from any > country to be validated reliably would simply be broken. If I were > still on the IESG when that came up, it'd be a guaranteed discuss > ballot from me. And not one that'd go away until the problem was properly fixed. > > There may well be issues to do with canonicalisation and there may be > discussion needed as to how that is split between signer and verifier. > But a country agnostic solution is definitely required at the > sign/verify/bind-to-cert level. > > S. > _______________________________________________ > 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_000D_01CE6452.BB2A71E0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYw ODE4MTYxM1owIwYJKoZIhvcNAQkEMRYEFHoSqDiSDeuakyL0kMR31ZtKTlPIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYrkZgq28bBbt7tPIIDOY+HXYlWbzTAe5//C9RjXX DdVpBhycGJo52kLylav/ZR4KDYZVkfMJc6UfwbwzE/tIjw3JZ00Xm1z7PBrFPD6nCImsKHHtPQLd hz09fZIcR0lw4Fea9/XopnBa2vU6Ya3gp/KopkIWdnzS2rT16enFHfDyuE/IyGvDwy1UxdgyrlD4 PxhYrpKkQGcM/I3qyBFuOceDQos5AgIeef+MMkkkr+NJn6Uzh+Y3qfGru+wbjBJEiJy9TZ1rLPAR US/efNzvg+D1xOy+FeSMvHpr2yuR5fcEBtYW4empKRtoZlfu1G4RfIuOvUo5l+/4MlOTRyIkrgAA AAAAAA== ------=_NextPart_000_000D_01CE6452.BB2A71E0-- From hadriel.kaplan@oracle.com Sat Jun 8 11:19: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 936EE21F9347 for ; Sat, 8 Jun 2013 11:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 Ajn3MtU7x2Gd for ; Sat, 8 Jun 2013 11:19:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39421F91A5 for ; Sat, 8 Jun 2013 11:18:59 -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 r58IIpTV024548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jun 2013 18:18:51 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 r58IIoP4002917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 18:18:51 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r58IIoGx018227; Sat, 8 Jun 2013 18:18:50 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-156-6.vpn.oracle.com (/10.154.156.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Jun 2013 11:18:50 -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: <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> Date: Sat, 8 Jun 2013 14:18:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 18:19:18 -0000 On Jun 7, 2013, at 10:23 PM, Henning Schulzrinne = wrote: > That's probably something we might want to flesh out a bit. My very = rough vision in the central database case would be something like the = following: >=20 > (1) Owner [doctors' office] says: "Please mint a cert that entitles = Doctor Smith [public key attached] to use our number 555 1234." [signed = by assignee] > (2) Database returns cert, which is handed to doctor. > (4) Doctor uses cert just like any other. If we want such a thing to work in the near-term timeframe, I don't = think it can work that way. For one thing I don't expect phones to be = able to do the signing themselves, nor their access service providers to = believe/trust the phones. As far as I know, today the Doctor phone's = service provider has to be in on it, and the provider equipment is = provisioned to know the Doctor's phone can claim another caller-id = (e.g., P-Associated-URI). I think it's a big jump to expect them to let = any subscriber to claim to be any number just because the supposed = holder of that number "authorized" them to. Even ignoring the P/S-CSCF = type equipment, there're a lot of other systems involved in this stuff, = for billing, CALEA, troubleshooting, etc. A more likely scenario is: (1) Doctor's office submits a request form with its service provider to = add Doctor's phone as authorized user for office number caller-id, or = with Doctor phone's service provider as a pull request. (2) The service providers fax each other authorization forms with legal = signatures. (2b) If there is some big central database model, then the Doctor = phone's service provider gets added as second source for the Office = number. (3) The Doctor phone's service provider adds into its databases the = Office caller-id as an authorized associated number for the phone to use = for outbound calls, which triggers associated identity handling during = next phone registration. (4) The Doctor makes an outbound call using the Office number, which the = service provider authorizes and signs using its own cert. -hadriel From michael.hammer@yaanatech.com Sat Jun 8 11:30: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 6135721F949F for ; Sat, 8 Jun 2013 11:30:17 -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_52=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 c+J3iUcrBShC for ; Sat, 8 Jun 2013 11:30:13 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4721F949D for ; Sat, 8 Jun 2013 11:30:13 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Sat, 8 Jun 2013 11:30:13 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "hgs@cs.columbia.edu" Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81k0Rag7WUmkWt6dxCH9sPJpkslruA//+M/0A= Date: Sat, 8 Jun 2013 18:30:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> In-Reply-To: <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@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.35] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01CE6454.AE51A5E0" MIME-Version: 1.0 Cc: "Brian.Rosen@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 18:30:17 -0000 ------=_NextPart_000_0022_01CE6454.AE51A5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question: Do we really care how many redirections occurred in the middle network hops if we know what the original source of the signaling was? Put another way, if we have a legitimate scape-goat for a problem call, do you need to catch all the stooges all at once? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, June 08, 2013 2:19 PM To: Henning Schulzrinne Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Permitted spoofing On Jun 7, 2013, at 10:23 PM, Henning Schulzrinne wrote: > That's probably something we might want to flesh out a bit. My very rough vision in the central database case would be something like the following: > > (1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor Smith [public key attached] to use our number 555 1234." [signed by assignee] > (2) Database returns cert, which is handed to doctor. > (4) Doctor uses cert just like any other. If we want such a thing to work in the near-term timeframe, I don't think it can work that way. For one thing I don't expect phones to be able to do the signing themselves, nor their access service providers to believe/trust the phones. As far as I know, today the Doctor phone's service provider has to be in on it, and the provider equipment is provisioned to know the Doctor's phone can claim another caller-id (e.g., P-Associated-URI). I think it's a big jump to expect them to let any subscriber to claim to be any number just because the supposed holder of that number "authorized" them to. Even ignoring the P/S-CSCF type equipment, there're a lot of other systems involved in this stuff, for billing, CALEA, troubleshooting, etc. A more likely scenario is: (1) Doctor's office submits a request form with its service provider to add Doctor's phone as authorized user for office number caller-id, or with Doctor phone's service provider as a pull request. (2) The service providers fax each other authorization forms with legal signatures. (2b) If there is some big central database model, then the Doctor phone's service provider gets added as second source for the Office number. (3) The Doctor phone's service provider adds into its databases the Office caller-id as an authorized associated number for the phone to use for outbound calls, which triggers associated identity handling during next phone registration. (4) The Doctor makes an outbound call using the Office number, which the service provider authorizes and signs using its own cert. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0022_01CE6454.AE51A5E0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYw ODE4MzAxMFowIwYJKoZIhvcNAQkEMRYEFGUeMpRqfuprudl9KCymj+blQnpuMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALFC9nuCFS8Rpb1jHDUy4L56DWksavQw6AxZ4xUdF GeV6fkTFGEIEp9w4BFxcwmQrXidg5HuHONmnEN/lhMZpMOp6nEMIbY8hki+aDKhadmOGz8onYy1z dDqQkX2wgYuJJeB+Uj6dQEQ6Z4rZjr6Fux2Mq/P4+OnRcuuo/csjdm4yQr6nLFyxbR6FBWMbqtlT g9G+ZcFAbECHEuOEdoqDJeVZQvMZR6Y4f/+5Y8SFZshUdpp0EEH0nI0MwmBfT+GZS3CQ+5D1mcnh 0E6STGPe+D0FUwJIHIrAvFCK20bdjiWJ0S+KdprjGcIwgUTF6rz7nmHIUMGLWoJmednShN6XbwAA AAAAAA== ------=_NextPart_000_0022_01CE6454.AE51A5E0-- From hadriel.kaplan@oracle.com Sat Jun 8 12:03: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 3374821F8BC0 for ; Sat, 8 Jun 2013 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 ugl9oBrUNdad for ; Sat, 8 Jun 2013 12:03:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 320D021F94DC for ; Sat, 8 Jun 2013 12:02:57 -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 r58J2lrq015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jun 2013 19:02:47 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 r58J2mjJ002845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 19:02:49 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 r58J2l8t013935; Sat, 8 Jun 2013 19:02:47 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-156-6.vpn.oracle.com (/10.154.156.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Jun 2013 12:02: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: <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> Date: Sat, 8 Jun 2013 15:02:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Brian.Rosen@neustar.biz" , "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 19:03:14 -0000 I think the hope was to proactively prevent a bogus call from = succeeding, as opposed to reactively hunting down the perpetrators after = it happened. The latter case should be possible now, since CDRs record = enough to backtrack to the upstream provider, and that provider's CDRs = can find its upstream provider, etc. -hadriel On Jun 8, 2013, at 2:30 PM, Michael Hammer = wrote: > Question: Do we really care how many redirections occurred in the = middle > network hops if we know what the original source of the signaling was? >=20 > Put another way, if we have a legitimate scape-goat for a problem = call, do > you need to catch all the stooges all at once? >=20 > Mike >=20 From richard@shockey.us Sat Jun 8 13:23: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 4B2FF21F9590 for ; Sat, 8 Jun 2013 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 J0LXwS8XcspA for ; Sat, 8 Jun 2013 13:23:32 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 0C42521F9248 for ; Sat, 8 Jun 2013 13:23:31 -0700 (PDT) Received: (qmail 14815 invoked by uid 0); 8 Jun 2013 20:22:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 8 Jun 2013 20:22:57 -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=P/ke3jt+If5rY8vKf8BkpIPMrtMnq8yp1L14lDP2xA8=; b=COps/QB6rHlYyoCl1YcSQfjHq3jhL7tYUX6K1MNK6KdVXKJbcUpPiYMi+zCcjASupq78l7MawevvtFn+Rd3+GzUqrfAXXt/nMKVpHb1uMiAwSpE4aspAnQ4wPgk8D+5u; Received: from [72.66.111.124] (port=54135 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UlPf7-0005cO-3m; Sat, 08 Jun 2013 14:22:57 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Henning Schulzrinne'" References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> In-Reply-To: <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> Date: Sat, 8 Jun 2013 16:22:53 -0400 Message-ID: <009401ce6485$f55e9ed0$e01bdc70$@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: AQHzDa2OziUvyJHeYP5EAIN/pOtmRALchml+AguTMeWYu6fg8A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: "'Rosen, Brian'" , stir@ietf.org Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 08 Jun 2013 20:23:41 -0000 Hadriel's thinking here makes a great deal of sense but we are coming really close to dealing with issues that are the ultimately the provenance of the NRA. First, it would be very helpful if anyone has any URL's that could point to other legislation similar to the US Truth in Caller ID act. It might be helpful to understand some other views here. Has the EC done anything similar especially in relation to their Privacy Directives? Second if you actually look at the FCC report to Congress Henning provided you can pretty easily read between the lines here. IMHO as an amateur telecom lawyer you can easily see that Truth in Caller ID Act is pretty useless. First enforcement requires proof of "intent to defraud" which is really hard to prove. So what is intent? Sort of like "absence of malice" in US Libel laws. Second it gave the FCC zero "authority to act" in dealing with third party service providers. The better solution would have been to make ALL spoofing of the signaling data illegal period, except in the cases where the consumer or enterprise could demonstrate a genuine need based on a strict set of criterion. Then the consumer or enterprise could present a "certificate of need" to the service provider that could provision the requirements as Hadriel suggests. The FCC report clearly saw that Congress understood the legitimate need for some permitted spoofing but took the wrong path to enforcing the requirement. KISS .. keying off the Full E.164 should be relatively easy to do even in intranational calling situations. The To: and From: should always be converted to + whenever possible at session origination. Describing how Permitted Spoofing COULD BE achieved is useful to document. In any event we certainly have to understand these issues but ultimately the definition of Permitted Spoofing is a NRA issue since the E.164 namespace is under the absolute control of the nation state. None of you wants to hear any sad tales about ENUM and e164.arpa I'm sure. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, June 08, 2013 2:19 PM To: Henning Schulzrinne Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Permitted spoofing On Jun 7, 2013, at 10:23 PM, Henning Schulzrinne wrote: > That's probably something we might want to flesh out a bit. My very rough vision in the central database case would be something like the following: > > (1) Owner [doctors' office] says: "Please mint a cert that entitles Doctor Smith [public key attached] to use our number 555 1234." [signed by assignee] > (2) Database returns cert, which is handed to doctor. > (4) Doctor uses cert just like any other. If we want such a thing to work in the near-term timeframe, I don't think it can work that way. For one thing I don't expect phones to be able to do the signing themselves, nor their access service providers to believe/trust the phones. As far as I know, today the Doctor phone's service provider has to be in on it, and the provider equipment is provisioned to know the Doctor's phone can claim another caller-id (e.g., P-Associated-URI). I think it's a big jump to expect them to let any subscriber to claim to be any number just because the supposed holder of that number "authorized" them to. Even ignoring the P/S-CSCF type equipment, there're a lot of other systems involved in this stuff, for billing, CALEA, troubleshooting, etc. A more likely scenario is: (1) Doctor's office submits a request form with its service provider to add Doctor's phone as authorized user for office number caller-id, or with Doctor phone's service provider as a pull request. (2) The service providers fax each other authorization forms with legal signatures. (2b) If there is some big central database model, then the Doctor phone's service provider gets added as second source for the Office number. (3) The Doctor phone's service provider adds into its databases the Office caller-id as an authorized associated number for the phone to use for outbound calls, which triggers associated identity handling during next phone registration. (4) The Doctor makes an outbound call using the Office number, which the service provider authorizes and signs using its own cert. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From tsearle@sipstacks.com Sun Jun 9 04:05: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 0F67B21F9458 for ; Sun, 9 Jun 2013 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 ROmGbmNBqDOp for ; Sun, 9 Jun 2013 04:05:50 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46C21F8D0D for ; Sun, 9 Jun 2013 04:05:50 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id 9so14241656iec.13 for ; Sun, 09 Jun 2013 04:05:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ge+PRw46CRkwiweDtzMiw8k3ysFmoW1uQjAi0cvT0UU=; b=cORKYY25QZ/Gre/OotgVfvHjSzU7fFL/Fmigi3WGLgpJc1NRPyl9OFma14mFxll1lq CZ2cN1bQtCPXF+yFcZtnxHVhj+fGdNaV+YOEnQ+RZoR/8AnO+hXh9n95kerY0JdhcH9Y cK2GqgwZF83qh1oLo9/PWC9XCu9Is6xypWlflVt1nRQCaa5XB8dg68fq13+CPQK7LfWb h6PpIAX9O3Xl060mD8Vad+GJ92xh9NCgDwSFdeYwg3wvEVs3MCCgYe7LZf+goEwMR8Ra kZq2rEHv9Vl0Mdey9uwpFB9hNTxBb7fmziWrun6jsMUld80Ye3IKfYmqbcO510Bw1rzV qe1g== MIME-Version: 1.0 X-Received: by 10.50.13.36 with SMTP id e4mr2151226igc.109.1370775949998; Sun, 09 Jun 2013 04:05:49 -0700 (PDT) Received: by 10.64.33.140 with HTTP; Sun, 9 Jun 2013 04:05:49 -0700 (PDT) Date: Sun, 9 Jun 2013 13:05:49 +0200 Message-ID: From: Torrey Searle To: stir@ietf.org Content-Type: multipart/alternative; boundary=089e01184784920dff04deb6a537 X-Gm-Message-State: ALoCoQkXgD/W4HnByyBpLAaRH5QfbAdNDvheKh717nA4rPSr//4LHQ/ithPQ46qMMtS8wLFjrKIV Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 09 Jun 2013 11:05:51 -0000 --089e01184784920dff04deb6a537 Content-Type: text/plain; charset=ISO-8859-1 >I'm not sure I understand the logic here. >Why would we trust a "not-evil" bit coming in from SS7/ISUP? >Why wouldn't all pink carriers just start setting that bit? In the case of SIP->SS7->SIP Wouldn't it be interesting for the Calling SIP party to put a signed hash of the called/calling number into A sip header, copy that into the SS7 User-To-User Header and then put it back into a SIP header on the destination sip leg? That way the Destination SIP network only needs to trust the originating sip network and not any intermediate SS7 networks. Regards, Torrey --089e01184784920dff04deb6a537 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
>I'm not sure I understand the logic here.
>Why would we trust a "not-evil" bit coming in from SS7/ISUP?
>Why wouldn't all pink carriers just start setting that bit?

=

In the case of
SIP->SS7->SIP  

Wouldn't it be interesting for the Calling SIP party to pu=
t a signed hash


of the called/calling number into A sip header, copy that into t=
he SS7 User-To-User
Header and then put it back into a SIP he=
ader on the destination sip leg?

That way the Destination SIP networ=
k only needs to trust the originating sip


network and not any intermediate SS7 networks.


= 
Regards,
Torrey
--089e01184784920dff04deb6a537-- From md3135@att.com Sun Jun 9 06:12: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 D0BF021F89C3 for ; Sun, 9 Jun 2013 06:12:15 -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=[AWL=-0.000, 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 daW2rQLZZODn for ; Sun, 9 Jun 2013 06:12:09 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id B577721F89A5 for ; Sun, 9 Jun 2013 06:12:08 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 82f74b15.0.67267.00-457.184009.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 09 Jun 2013 13:12:08 +0000 (UTC) X-MXL-Hash: 51b47f2843d5ce09-c0ce47585121fb1a1d4d67a8b86d06ad08028552 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 r59DC78x003588; Sun, 9 Jun 2013 09:12:08 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r59DBxUs003534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 09:12:01 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 9 Jun 2013 13:11:42 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Sun, 9 Jun 2013 09:11:46 -0400 From: "DOLLY, MARTIN C" To: Torrey Searle , "stir@ietf.org" Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially) Thread-Index: AQHOZQFV0gesIXhra0GV0mU1bZ3+WZktW7Zg Date: Sun, 9 Jun 2013 13:11:46 +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.91.79] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560215F214MISOUT7MSGUSR9I_" 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=K9eV6VqI c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=kqiTwUOr0zsA:10 a=VLxPM_b3LV4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=oOBisLQmZ] X-AnalysisOut: [4cA:10 a=48vgC7mUAAAA:8 a=7g3uMaVVxtA19EAyaMkA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=-scbWLCQhTX2v_XW:21 a=j65mK-M] X-AnalysisOut: [CDbX_DoYJ:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=s5JPDEVjV] X-AnalysisOut: [jg85UmpewkA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7] X-AnalysisOut: [Yk6K0A:10 a=frz4AuCg-hUA:10 a=7QrYW_-H3AVgE3GS:21] Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 09 Jun 2013 13:12:15 -0000 --_000_E42CCDDA6722744CB241677169E836560215F214MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How many octets? From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Tor= rey Searle Sent: Sunday, June 09, 2013 7:06 AM To: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly) >I'm not sure I understand the logic here. >Why would we trust a "not-evil" bit coming in from SS7/ISUP? >Why wouldn't all pink carriers just start setting that bit? In the case of SIP->SS7->SIP Wouldn't it be interesting for the Calling SIP party to put a signed hash of the called/calling number into A sip header, copy that into the SS7 User= -To-User Header and then put it back into a SIP header on the destination sip leg? That way the Destination SIP network only needs to trust the originating si= p network and not any intermediate SS7 networks. Regards, Torrey --_000_E42CCDDA6722744CB241677169E836560215F214MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How many octets?

 <= /p>

From: stir-bou= nces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Torrey Searle
Sent: Sunday, June 09, 2013 7:06 AM
To: stir@ietf.org
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

 

>I'm not sure I understand the logic here.
>Why would we trust a "not-evil" bit coming in from SS7/I=
SUP?
>Why wouldn't all pink carriers just=
 start setting that bit?

In the case of
SIP->SS7->SIP  

=

Wouldn't it be interesting for the Calling SIP party to put a signed h=
ash

of the called/calling number into A sip header, copy that into the SS7=
 User-To-User
Header and then put it back into a SIP header on the destination sip l=
eg?

That way the Destination SIP network only needs to trust the ori=
ginating sip

network and not any intermediate SS7 ne=
tworks.

Regards,
Torrey
--_000_E42CCDDA6722744CB241677169E836560215F214MISOUT7MSGUSR9I_-- From tsearle@sipstacks.com Sun Jun 9 06:55: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 F0E8B21F901F for ; Sun, 9 Jun 2013 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 c5KVQGIe2lm2 for ; Sun, 9 Jun 2013 06:55:27 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32A21F8CDD for ; Sun, 9 Jun 2013 06:55:27 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x14so14511949ief.12 for ; Sun, 09 Jun 2013 06:55:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Jo3QJ8wKXsC8CGQ3fvW80pAk9Da228HiVZu5q2SEAkk=; b=M81Uc39ibGtBc7MzMWVflFzDCI5XgG+2Jr1g6P00SFAZq2Yd4KLo7jnUZMlEeoOnU0 f5nSk/8Tq367He0IU40LiQ8v0FEHXkDaR32eka6OSLj6bMaNMGl5A5HSzdebKMM8D+zr YHCEyihG5QH5QUegjaVh7U10EzwSluIhITMWBoj0fq4yj1z3D0fwZrNYz00/VRh5r4u7 rhj3W4vhO/ghQuMYcx1IiaQtzHUYNqq6DjTMer8WlYCEQwKGm2LOZo/G3FxG12FbCd4x msLb9vGrfOKbojTigKdAh5XFAiy8IqypksJXiKLgCeKB6GjrXu+0ZiWQDxlCgdy0p4pP /PnA== MIME-Version: 1.0 X-Received: by 10.50.62.108 with SMTP id x12mr2397963igr.66.1370786126817; Sun, 09 Jun 2013 06:55:26 -0700 (PDT) Received: by 10.64.33.140 with HTTP; Sun, 9 Jun 2013 06:55:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Jun 2013 15:55:26 +0200 Message-ID: From: Torrey Searle To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7b5d900f271f1504deb904ad X-Gm-Message-State: ALoCoQk59O1Vh/alyCwzJrGjOFyxZPA6SGLSWnYpcKIhTo6yND0oJs1NsrpKN2dsdGqSBxQ5MXXs Cc: "stir@ietf.org" Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 09 Jun 2013 13:55:28 -0000 --047d7b5d900f271f1504deb904ad Content-Type: text/plain; charset=ISO-8859-1 The only restriction is that length is encoded in one byte. So that means 255 bytes of data. As binary data is allowed, base64 encoding isn't needed either. Torrey On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C wrote: > How many octets?**** > > ** ** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Torrey Searle > *Sent:* Sunday, June 09, 2013 7:06 AM > *To:* stir@ietf.org > *Subject:* Re: [stir] A 4474 that will work through SBCs > (generally/potentially)**** > > ** ** > > >I'm not sure I understand the logic here.**** > > >Why would we trust a "not-evil" bit coming in from SS7/ISUP?**** > > >Why wouldn't all pink carriers just start setting that bit? > > **** > > In the case of**** > > SIP->SS7->SIP > > **** > > Wouldn't it be interesting for the Calling SIP party to put a signed hash > > **** > > of the called/calling number into A sip header, copy that into the SS7 User-To-User**** > > Header and then put it back into a SIP header on the destination sip leg? > > That way the Destination SIP network only needs to trust the originating sip > > **** > > network and not any intermediate SS7 networks. > > **** > > Regards, > Torrey**** > > --047d7b5d900f271f1504deb904ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The only restriction is that length is encoded in one= byte.=A0 So that means 255 bytes of data.=A0 As binary data is allowed, ba= se64 encoding isn't needed either.

Torrey


On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, M= ARTIN C <md3135@att.com> wrote:

How many octets?

=A0<= /p>

From: stir-bounces@ietf.org [mailto:stir-= bounces@ietf.org] On Behalf Of Torrey Searle
Sent: Sunday, June 09, 2013 7:06 AM
To: stir@ietf.org=
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

=A0

>I'm not sure I understand the logic here.
>Why would we trust a "not-evil" bit coming in from SS7/I=
SUP?
>Why wouldn't all pink carriers =
just start setting that bit?

In the case of
SIP->SS7->SIP=A0 

<=
u>
Wouldn't it be interesting for the Calling SIP party to put a sign=
ed hash

of the called/calling number into A sip header, copy that into the SS7=
 User-To-User
Header and then put it back into a SIP header on the destination sip l=
eg?

That way the Destination SIP network only needs to trust the ori=
ginating sip

network and not any intermediate SS7 ne=
tworks.

Regards,
Torrey

--047d7b5d900f271f1504deb904ad-- From md3135@att.com Sun Jun 9 07:00: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 2971721F8605 for ; Sun, 9 Jun 2013 07:00:23 -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=[AWL=-0.000, 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 oaYTehStHiOE for ; Sun, 9 Jun 2013 07:00:07 -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 9DA5821F9273 for ; Sun, 9 Jun 2013 07:00:06 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 66a84b15.0.87424.00-482.239225.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 09 Jun 2013 14:00:06 +0000 (UTC) X-MXL-Hash: 51b48a6644c6f2f8-190696cdc1065755c092ea455872b06c868b9803 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 r59E05VB020804; Sun, 9 Jun 2013 10:00:06 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r59DxtOH020715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 10:00:03 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 9 Jun 2013 13:59:45 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; Sun, 9 Jun 2013 09:59:49 -0400 From: "DOLLY, MARTIN C" To: Torrey Searle Thread-Topic: [stir] A 4474 that will work through SBCs (generally/potentially) Thread-Index: AQHOZRkG522i7Eop60OX4inb8/NGCpktaNPQ Date: Sun, 9 Jun 2013 13:59:49 +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.91.79] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836560215F29FMISOUT7MSGUSR9I_" 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=f5n/8pOM c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=kqiTwUOr0zsA:10 a=VLxPM_b3LV4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=oOBisLQmZ] X-AnalysisOut: [4cA:10 a=Wzj1v9PIAAAA:8 a=48vgC7mUAAAA:8 a=Tf-T7_mscLFLlQe] X-AnalysisOut: [bWHsA:9 a=CjuIK1q_8ugA:10 a=Hn2pRle-0NMA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=GRojm63Bbc7ea3jT:21 a=0wy06DbGzWQO] X-AnalysisOut: [4XW0:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ozMbyQ2gMtEMtt] X-AnalysisOut: [3OFVIA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0] X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=VgO5lfPA_ZBNszz] X-AnalysisOut: [P:21 a=B5gwFnjv3BxDfhsc:21 a=PmbR2ltjFVp5MqK7:21] Cc: "stir@ietf.org" Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 09 Jun 2013 14:00:23 -0000 --_000_E42CCDDA6722744CB241677169E836560215F29FMISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Answer the question... I wrote the ISUP standard From: Torrey Searle [mailto:tsearle@sipstacks.com] Sent: Sunday, June 09, 2013 9:55 AM To: DOLLY, MARTIN C Cc: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly) The only restriction is that length is encoded in one byte. So that means = 255 bytes of data. As binary data is allowed, base64 encoding isn't needed= either. Torrey On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C > wrote: How many octets? From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Torrey Searle Sent: Sunday, June 09, 2013 7:06 AM To: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potential= ly) >I'm not sure I understand the logic here. >Why would we trust a "not-evil" bit coming in from SS7/ISUP? >Why wouldn't all pink carriers just start setting that bit? In the case of SIP->SS7->SIP Wouldn't it be interesting for the Calling SIP party to put a signed hash of the called/calling number into A sip header, copy that into the SS7 User= -To-User Header and then put it back into a SIP header on the destination sip leg? That way the Destination SIP network only needs to trust the originating si= p network and not any intermediate SS7 networks. Regards, Torrey --_000_E42CCDDA6722744CB241677169E836560215F29FMISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Answer the question…= ; I wrote the ISUP standard

 <= /p>

From: Torrey S= earle [mailto:tsearle@sipstacks.com]
Sent: Sunday, June 09, 2013 9:55 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

 

The only restriction = is that length is encoded in one byte.  So that means 255 bytes of dat= a.  As binary data is allowed, base64 encoding isn't needed either.

Torrey

 

On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C <= md3135@att.com> = wrote:

How many octets?

 

From: stir-bounces@iet= f.org [mailto:stir-bounces@ietf.org] On Behalf Of Torrey Searle
Sent: Sunday, June 09, 2013 7:06 AM
To: stir@ietf.org=
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

 

>I'm not sure I understand the logic here.
>Why would we trust a "not-evil" bit coming in from SS7/I=
SUP?
>Why wouldn't all pink carriers just=
 start setting that bit?
In the case of
SIP->SS7->SIP  

Wouldn't it be interesting for the Call=
ing SIP party to put a signed hash


of the called/calling number into A sip header, copy that into the SS7=
 User-To-User


Header and then put it back into a SIP =
header on the destination sip leg?

That way the Destination SIP netw=
ork only needs to trust the originating sip


network and not any intermediate SS7 ne=
tworks.


Regards,
Torrey

 

--_000_E42CCDDA6722744CB241677169E836560215F29FMISOUT7MSGUSR9I_-- From br@brianrosen.net Mon Jun 10 05:53: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 0989521F8E8F for ; Mon, 10 Jun 2013 05:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.414 X-Spam-Level: X-Spam-Status: No, score=-100.414 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 8GpnCto1gYDo for ; Mon, 10 Jun 2013 05:53:10 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0198921F869F for ; Mon, 10 Jun 2013 05:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=5JHB+wAUvraC1K9cdiQdiQJAafU26AKV8UBizM6JlQo=; b=c7VPIOxUOcO6VkqHGXI+QbXNNnewamGGHUsVsB8YeNT2lrHzS1SqBWGVI1nSNkTMFQXrUGipBNQIfioxk791CmoLRRiG9ODwyONmNR7EwUCbC7W2g6d/zKvJ4nm3jauxsjWNjsKiH3SAWuwGGJ7NadWm/geXfgIsRQaiSgdyTrY=; Received: from neustargw.va.neustar.com ([209.173.53.233]:33980 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Um1ag-0000BU-Gz; Mon, 10 Jun 2013 08:52:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DAA8B@ex2k10mb2.corp.yaanatech.com> Date: Mon, 10 Jun 2013 08:52:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2606ED2D-B6EF-43D1-A059-6923222118EF@brianrosen.net> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> <51B26886.8020000@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3A03DAA8B@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 12:53:15 -0000 > The current headers are too over-loaded with usages at this point to = be much > help here. We have a hypothesis that numbers going between service providers are = always convertible to e.164 programatically. If you have relevant = examples where that is not true, please send them. I'd rather not have new headers if we can avoid it. Brian >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Paul > Kyzivat > Sent: Friday, June 07, 2013 7:11 PM > To: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? >=20 > The sensible thing would be to expect the numbers to be "pure" E.164 = (with > the +), before signing. But that might take some doing. >=20 > Thanks, > Paul >=20 > On 6/7/13 6:51 PM, Richard Shockey wrote: >> There are only a limited number of countries that still support=20 >> variable length dial plans. Germany is the worst case. >>=20 >> There are variations in localized dialing schemes but the solution = for=20 >> that was always convert the local number to the full E.164 before = look > ups. >>=20 >> We went round and round on this in ENUM. >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Stephen Farrell >> Sent: Friday, June 07, 2013 6:21 PM >> To: Paul Kyzivat >> Cc: stir@ietf.org; Henning Schulzrinne >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other=20 >> middle boxes? >>=20 >>=20 >>=20 >> On 06/07/2013 09:17 PM, Paul Kyzivat wrote: >>>>=20 >>>> At least for countries with fixed-length numbers, such as the US,=20= >>>> taking the last 10 digits would seem to work, if the number string=20= >>>> is longer than that. >>>=20 >>> That's why I asked if this was just for NANP. >>> But even if we are only addressing concerns of the FCC, there are=20 >>> calls into the US from outside, and from inside to outside. So not=20= >>> all the numbers are going to be NANP numbers, and not all will be=20 >>> fixed >> length. >>=20 >> IMO a solution that did not allow signatures over numbers from any=20 >> country to be validated reliably would simply be broken. If I were=20 >> still on the IESG when that came up, it'd be a guaranteed discuss=20 >> ballot from me. And not one that'd go away until the problem was = properly > fixed. >>=20 >> There may well be issues to do with canonicalisation and there may be=20= >> discussion needed as to how that is split between signer and = verifier.=20 >> But a country agnostic solution is definitely required at the=20 >> sign/verify/bind-to-cert level. >>=20 >> S. >> _______________________________________________ >> 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Mon Jun 10 05:57: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 4C5F221F8B35 for ; Mon, 10 Jun 2013 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 XemMyHuwUVES for ; Mon, 10 Jun 2013 05:57:35 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70321F8F4A for ; Mon, 10 Jun 2013 05:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370868933; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=OIbbkBoqdm 6NMhZQILjy4jFuftCl7KNLDe1czbAfF5Q=; b=n/Sh6Nj8hLqNaETWYKm3GlH1HE e8CmFmFNnrUEpeeyKymYsRWkwdMfO62nJBi3r4XLZ2ce68YVFDuYLGvIM0hw== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19346061; Mon, 10 Jun 2013 08:55:31 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 08:57:18 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 08:57:13 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81QVR2lI4PHEaFqY34c3fHK5ksZHCAgAADK4CAAAkdAIACvoMA Date: Mon, 10 Jun 2013 12:57:12 +0000 Message-ID: References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9K2Ml2bh0FzerJgisEXSQA== Content-Type: text/plain; charset="us-ascii" Content-ID: <880E09F043FFED41BCF2DA4C1CAF81AF@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "hgs@cs.columbia.edu" , Michael Hammer , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 12:57:40 -0000 I agree, the point is to prevent bad calls. I understand that following ca= lls back through CDRs is very difficult and time consuming from the point = of view of the law enforcement agency doing the tracking. That's why Henni= ng would like us to come up with a way of automating that traceback. Brian On Jun 8, 2013, at 3:02 PM, Hadriel Kaplan wrot= e: >=20 > I think the hope was to proactively prevent a bogus call from succeeding,= as opposed to reactively hunting down the perpetrators after it happened. = The latter case should be possible now, since CDRs record enough to backtr= ack to the upstream provider, and that provider's CDRs can find its upstrea= m provider, etc. >=20 > -hadriel >=20 >=20 > On Jun 8, 2013, at 2:30 PM, Michael Hammer = wrote: >=20 >> Question: Do we really care how many redirections occurred in the middl= e >> network hops if we know what the original source of the signaling was? >>=20 >> Put another way, if we have a legitimate scape-goat for a problem call, = do >> you need to catch all the stooges all at once? >>=20 >> Mike >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Mon Jun 10 06:06: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 DA8B621F8CB4 for ; Mon, 10 Jun 2013 06:06:52 -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, 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 NikyUoW61k4Q for ; Mon, 10 Jun 2013 06:06:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4212C21F8AC2 for ; Mon, 10 Jun 2013 06:06:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 81B98264588; Mon, 10 Jun 2013 15:06:38 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6725235C070; Mon, 10 Jun 2013 15:06:38 +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; Mon, 10 Jun 2013 15:06:38 +0200 From: To: "Rosen, Brian" , "stir@ietf.org" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpku4ZLA Date: Mon, 10 Jun 2013 13:06:37 +0000 Message-ID: <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> In-Reply-To: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> 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="iso-8859-1" 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.5.21.113319 Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 13:06:53 -0000 > Can we come up with examples where a canonicalized e.164 would NOT pass e= nd to end? I'm not sure the following would fall into your category but in addition to= prefixing thaty's already been mentioned, you may also have cases where th= e conversion from the dialing plan to the numbering plan involves a "degree= of complexity" that cannot be expected from some endpoints because it is m= ore complex than just "replace the national prefix, aka 'trunk prefix', wit= h the relevant geographic country code" to get the full E.164 canonical for= m. (for example, supposing 0 as a national trunk code, some dialing plans m= ap 0-XXX to _several_ geographic country codes +CC-XXX depending on the val= ue of XXX).=20 One simple way to support these formats is to allow the endpoint (eg a PBX)= to always send +CC-XXX with one given CC (and therefore potentially incorr= ect canonical form) and correct it with the right mapping downstream. On ma= y argue that it is a bit of a hack to make up for the lack of support of a = phone-context by the endpoints, but you generally have to make do without i= t.=20 Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Friday, June 07, 2013 7:20 PM To: stir@ietf.org Subject: [stir] Can canonical phone numbers survive SBCs and other middle b= oxes? The fundamental idea that we have here is that you sign a set of informatio= n with a credential, and you pass the signature and a pointer to the creden= tial in SIP signaling.=20 We have some disagreements about what is signed. Henning has proposed that we canonicalize the From and To phone numbers, we= include a timestamp and some form of call-id, possibly the INSIPID id. =A0 There are assertions that you can't use From/To, because middle boxes chang= e them. =A0Some have suggested using P-A-I and other headers instead. Hadriel wrote a draft about why From and To get modified: http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt After reading it, I am unclear if a canonicalized e.164 would make it throu= gh. =A0The reasons given seem to indicate they would. =A0They change domain= s, they change prefixes, but they don't seem to change the actual telephone= number. Can we come up with examples where a canonicalized e.164 would NOT pass end= to end? Brian ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From brian.rosen@neustar.biz Mon Jun 10 06: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 9875821F8C40 for ; Mon, 10 Jun 2013 06:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 IGQVsfhoQGcn for ; Mon, 10 Jun 2013 06:28:48 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3B21F8443 for ; Mon, 10 Jun 2013 06:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370871109; x=1686227543; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=L7Mj/Wfedh OKfaSM8fgRyQ1/V8qGwIixzKUUvpY3zQM=; b=ib1dmZrRajlLGDT38vB228IloR AdMfSBjTroKxsOhav/qBowihH/fo0N+dh7sQmfytKu7qcvutZJ2x9I9E7lyg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24878689; Mon, 10 Jun 2013 09:31:48 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 09:27:42 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 09:27:37 -0400 From: "Rosen, Brian" To: " " Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZdtbMV9e71w7JES9tLUjczQfdZkvM+CA Date: Mon, 10 Jun 2013 13:27:36 +0000 Message-ID: <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fpY0WLSy9Mpbob526p/IWQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 13:28:52 -0000 If both the endpoints and their SPs understand the rules, then they can gen= erate the signature and check it. Might have problems with intermediaries that couldn't do that unless the To= was rewritten at some point. It would seem to me that in order to route = these calls, that's what would have to happen unless you are using P-A-I pa= ssed between carriers to carry the decoded e.164. Brian On Jun 10, 2013, at 9:06 AM, wrote: >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >=20 > I'm not sure the following would fall into your category but in addition = to prefixing thaty's already been mentioned, you may also have cases where = the conversion from the dialing plan to the numbering plan involves a "degr= ee of complexity" that cannot be expected from some endpoints because it is= more complex than just "replace the national prefix, aka 'trunk prefix', w= ith the relevant geographic country code" to get the full E.164 canonical f= orm. (for example, supposing 0 as a national trunk code, some dialing plans= map 0-XXX to _several_ geographic country codes +CC-XXX depending on the v= alue of XXX).=20 >=20 > One simple way to support these formats is to allow the endpoint (eg a PB= X) to always send +CC-XXX with one given CC (and therefore potentially inco= rrect canonical form) and correct it with the right mapping downstream. On = may argue that it is a bit of a hack to make up for the lack of support of = a phone-context by the endpoints, but you generally have to make do without= it.=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Friday, June 07, 2013 7:20 PM > To: stir@ietf.org > Subject: [stir] Can canonical phone numbers survive SBCs and other middle= boxes? >=20 > The fundamental idea that we have here is that you sign a set of informat= ion with a credential, and you pass the signature and a pointer to the cred= ential in SIP signaling.=20 >=20 > We have some disagreements about what is signed. >=20 > Henning has proposed that we canonicalize the From and To phone numbers, = we include a timestamp and some form of call-id, possibly the INSIPID id. = =20 >=20 > There are assertions that you can't use From/To, because middle boxes cha= nge them. Some have suggested using P-A-I and other headers instead. >=20 > Hadriel wrote a draft about why From and To get modified: > http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >=20 > After reading it, I am unclear if a canonicalized e.164 would make it thr= ough. The reasons given seem to indicate they would. They change domains,= they change prefixes, but they don't seem to change the actual telephone n= umber. >=20 > Can we come up with examples where a canonicalized e.164 would NOT pass e= nd to end? >=20 > Brian >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From philippe.fouquart@orange.com Mon Jun 10 07:09: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 D77E021F84B6 for ; Mon, 10 Jun 2013 07:09:23 -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 lfAJXJXrnHym for ; Mon, 10 Jun 2013 07:09:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFA521F848E for ; Mon, 10 Jun 2013 07:09:19 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 854FA26469A; Mon, 10 Jun 2013 16:09:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5753B35C072; Mon, 10 Jun 2013 16:09:18 +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; Mon, 10 Jun 2013 16:09:18 +0200 From: To: "Rosen, Brian" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOY6NMqrzJV4FsFkGjktiLvkAqlpku4ZLA///yKgCAACPs4A== Date: Mon, 10 Jun 2013 14:09:18 +0000 Message-ID: <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> In-Reply-To: <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> 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.6.10.132420 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 14:09:24 -0000 Thanks. Am I then right in rephrasing this as "it isn't going to be a probl= em if and only if the intermediary that corrects the canonical form is also= able to [re]sign the [corrected] number?"=20 For CgPNs, I guess this would work for a pbx using numbers under ranges of = their service provider (or ported to it), but may not easily work for (more= interesting) cases where the CgPN is completely unrelated with the call ce= ntre that initiated the call (eg a concierge service using their customer's= individual number, the "Permitted spoofing" case).=20 Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Monday, June 10, 2013 3:28 PM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? If both the endpoints and their SPs understand the rules, then they can gen= erate the signature and check it. Might have problems with intermediaries that couldn't do that unless the To= was rewritten at some point. It would seem to me that in order to route = these calls, that's what would have to happen unless you are using P-A-I pa= ssed between carriers to carry the decoded e.164. Brian On Jun 10, 2013, at 9:06 AM, wrote: >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >=20 > I'm not sure the following would fall into your category but in addition = to prefixing thaty's already been mentioned, you may also have cases where = the conversion from the dialing plan to the numbering plan involves a "degr= ee of complexity" that cannot be expected from some endpoints because it is= more complex than just "replace the national prefix, aka 'trunk prefix', w= ith the relevant geographic country code" to get the full E.164 canonical f= orm. (for example, supposing 0 as a national trunk code, some dialing plans= map 0-XXX to _several_ geographic country codes +CC-XXX depending on the v= alue of XXX).=20 >=20 > One simple way to support these formats is to allow the endpoint (eg a PB= X) to always send +CC-XXX with one given CC (and therefore potentially inco= rrect canonical form) and correct it with the right mapping downstream. On = may argue that it is a bit of a hack to make up for the lack of support of = a phone-context by the endpoints, but you generally have to make do without= it.=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Friday, June 07, 2013 7:20 PM > To: stir@ietf.org > Subject: [stir] Can canonical phone numbers survive SBCs and other middle= boxes? >=20 > The fundamental idea that we have here is that you sign a set of informat= ion with a credential, and you pass the signature and a pointer to the cred= ential in SIP signaling.=20 >=20 > We have some disagreements about what is signed. >=20 > Henning has proposed that we canonicalize the From and To phone numbers, = we include a timestamp and some form of call-id, possibly the INSIPID id.= =20=20 >=20 > There are assertions that you can't use From/To, because middle boxes cha= nge them. Some have suggested using P-A-I and other headers instead. >=20 > Hadriel wrote a draft about why From and To get modified: > http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >=20 > After reading it, I am unclear if a canonicalized e.164 would make it thr= ough. The reasons given seem to indicate they would. They change domains,= they change prefixes, but they don't seem to change the actual telephone n= umber. >=20 > Can we come up with examples where a canonicalized e.164 would NOT pass e= nd to end? >=20 > Brian >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From brian.rosen@neustar.biz Mon Jun 10 07:14: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 98AD921F8F3E for ; Mon, 10 Jun 2013 07:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 TozoyOjoO-aE for ; Mon, 10 Jun 2013 07:14:32 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 79AE921F85E6 for ; Mon, 10 Jun 2013 07:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370873565; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=rL0EWgATI/ 6ISavDTMpEwwPGvv5IAHXPE6qbdUDOCJM=; b=UxpHgUen1eCC8SNVqGu5cpUB1m GvmtAcGW8YyyD/gTALrPmcHlnenmgPZFKmELM3+nUj9EG3dG/4MOHHAu7D6Q== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19349174; Mon, 10 Jun 2013 10:12:44 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 10:14:30 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 10:14:29 -0400 From: "Rosen, Brian" To: "philippe.fouquart@orange.com" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTQ== Date: Mon, 10 Jun 2013 14:14:28 +0000 Message-ID: <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uOpLkDv7tQOXV0XSE2FVEQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 14:14:36 -0000 I never thought about resigning. Whatever element signs has to be authoritative for the e.164. In your exam= ple, who do you think would do the initial signing and who would re-sign? Brian On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: > Thanks. Am I then right in rephrasing this as "it isn't going to be a pro= blem if and only if the intermediary that corrects the canonical form is al= so able to [re]sign the [corrected] number?"=20 >=20 > For CgPNs, I guess this would work for a pbx using numbers under ranges o= f their service provider (or ported to it), but may not easily work for (mo= re interesting) cases where the CgPN is completely unrelated with the call = centre that initiated the call (eg a concierge service using their customer= 's individual number, the "Permitted spoofing" case).=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Monday, June 10, 2013 3:28 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > If both the endpoints and their SPs understand the rules, then they can g= enerate the signature and check it. > Might have problems with intermediaries that couldn't do that unless the = To was rewritten at some point. It would seem to me that in order to rout= e these calls, that's what would have to happen unless you are using P-A-I = passed between carriers to carry the decoded e.164. >=20 > Brian >=20 >=20 > On Jun 10, 2013, at 9:06 AM, > wrote: >=20 >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>=20 >> I'm not sure the following would fall into your category but in addition= to prefixing thaty's already been mentioned, you may also have cases where= the conversion from the dialing plan to the numbering plan involves a "deg= ree of complexity" that cannot be expected from some endpoints because it i= s more complex than just "replace the national prefix, aka 'trunk prefix', = with the relevant geographic country code" to get the full E.164 canonical = form. (for example, supposing 0 as a national trunk code, some dialing plan= s map 0-XXX to _several_ geographic country codes +CC-XXX depending on the = value of XXX).=20 >>=20 >> One simple way to support these formats is to allow the endpoint (eg a P= BX) to always send +CC-XXX with one given CC (and therefore potentially inc= orrect canonical form) and correct it with the right mapping downstream. On= may argue that it is a bit of a hack to make up for the lack of support of= a phone-context by the endpoints, but you generally have to make do withou= t it.=20 >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Rosen, Brian >> Sent: Friday, June 07, 2013 7:20 PM >> To: stir@ietf.org >> Subject: [stir] Can canonical phone numbers survive SBCs and other middl= e boxes? >>=20 >> The fundamental idea that we have here is that you sign a set of informa= tion with a credential, and you pass the signature and a pointer to the cre= dential in SIP signaling.=20 >>=20 >> We have some disagreements about what is signed. >>=20 >> Henning has proposed that we canonicalize the From and To phone numbers,= we include a timestamp and some form of call-id, possibly the INSIPID id. = =20 >>=20 >> There are assertions that you can't use From/To, because middle boxes ch= ange them. Some have suggested using P-A-I and other headers instead. >>=20 >> Hadriel wrote a draft about why From and To get modified: >> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>=20 >> After reading it, I am unclear if a canonicalized e.164 would make it th= rough. The reasons given seem to indicate they would. They change domains= , they change prefixes, but they don't seem to change the actual telephone = number. >>=20 >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >>=20 >> Brian >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Mon Jun 10 08:04: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 8395921F90EF for ; Mon, 10 Jun 2013 08:04:19 -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, 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 1q3xiUbcHDrg for ; Mon, 10 Jun 2013 08:04:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EC8FC21F85E6 for ; Mon, 10 Jun 2013 08:04:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 12EC2264267; Mon, 10 Jun 2013 17:04:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D8BBF35C07A; Mon, 10 Jun 2013 17:04:12 +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; Mon, 10 Jun 2013 17:04:12 +0200 From: To: "Rosen, Brian" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTV92NE3ldI+k2ZlJ4diB8iI5kvCIiQ Date: Mon, 10 Jun 2013 15:04:11 +0000 Message-ID: <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> In-Reply-To: <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> 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.6.10.132420 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:04:20 -0000 I assume the initial signing to be done by the endpoint, the pbx, which has= authority over the full E.164 number. If the canonical form is incorrect (the international format is incorrect o= r the number is only provided in national format), I would have imagined th= at the intermediary would have to provide a correct canonical form and (?) = resign.=20=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Monday, June 10, 2013 4:14 PM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? I never thought about resigning. Whatever element signs has to be authoritative for the e.164. In your exam= ple, who do you think would do the initial signing and who would re-sign? Brian On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: > Thanks. Am I then right in rephrasing this as "it isn't going to be a pro= blem if and only if the intermediary that corrects the canonical form is al= so able to [re]sign the [corrected] number?"=20 >=20 > For CgPNs, I guess this would work for a pbx using numbers under ranges o= f their service provider (or ported to it), but may not easily work for (mo= re interesting) cases where the CgPN is completely unrelated with the call = centre that initiated the call (eg a concierge service using their customer= 's individual number, the "Permitted spoofing" case).=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Monday, June 10, 2013 3:28 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > If both the endpoints and their SPs understand the rules, then they can g= enerate the signature and check it. > Might have problems with intermediaries that couldn't do that unless the = To was rewritten at some point. It would seem to me that in order to rout= e these calls, that's what would have to happen unless you are using P-A-I = passed between carriers to carry the decoded e.164. >=20 > Brian >=20 >=20 > On Jun 10, 2013, at 9:06 AM, > wrote: >=20 >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>=20 >> I'm not sure the following would fall into your category but in addition= to prefixing thaty's already been mentioned, you may also have cases where= the conversion from the dialing plan to the numbering plan involves a "deg= ree of complexity" that cannot be expected from some endpoints because it i= s more complex than just "replace the national prefix, aka 'trunk prefix', = with the relevant geographic country code" to get the full E.164 canonical = form. (for example, supposing 0 as a national trunk code, some dialing plan= s map 0-XXX to _several_ geographic country codes +CC-XXX depending on the = value of XXX).=20 >>=20 >> One simple way to support these formats is to allow the endpoint (eg a P= BX) to always send +CC-XXX with one given CC (and therefore potentially inc= orrect canonical form) and correct it with the right mapping downstream. On= may argue that it is a bit of a hack to make up for the lack of support of= a phone-context by the endpoints, but you generally have to make do withou= t it.=20 >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Rosen, Brian >> Sent: Friday, June 07, 2013 7:20 PM >> To: stir@ietf.org >> Subject: [stir] Can canonical phone numbers survive SBCs and other middl= e boxes? >>=20 >> The fundamental idea that we have here is that you sign a set of informa= tion with a credential, and you pass the signature and a pointer to the cre= dential in SIP signaling.=20 >>=20 >> We have some disagreements about what is signed. >>=20 >> Henning has proposed that we canonicalize the From and To phone numbers,= we include a timestamp and some form of call-id, possibly the INSIPID id.= =20=20 >>=20 >> There are assertions that you can't use From/To, because middle boxes ch= ange them. Some have suggested using P-A-I and other headers instead. >>=20 >> Hadriel wrote a draft about why From and To get modified: >> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>=20 >> After reading it, I am unclear if a canonicalized e.164 would make it th= rough. The reasons given seem to indicate they would. They change domains= , they change prefixes, but they don't seem to change the actual telephone = number. >>=20 >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >>=20 >> Brian >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From brian.rosen@neustar.biz Mon Jun 10 08:25: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 A3D1B21F9711 for ; Mon, 10 Jun 2013 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 aJ7QO0TdL+ct for ; Mon, 10 Jun 2013 08:25:27 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4381921F9815 for ; Mon, 10 Jun 2013 08:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370877818; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=g5kcSizs1m n2MeAXH/fYSDmvPSy5B49n/C8Atkcjwho=; b=DmuOAiRDDvMxI/ztB/cMlMtOtb IykM19zXLcQRIiCTgc5BxTQv1IMJtJ8PeX2E5eIk6GPwz5VbujKl+nsVuZNg== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19352947; Mon, 10 Jun 2013 11:23:36 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 11:25:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 11:25:21 -0400 From: "Rosen, Brian" To: "philippe.fouquart@orange.com" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oA= Date: Mon, 10 Jun 2013 15:25:20 +0000 Message-ID: In-Reply-To: <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 0ufeAVj485mUow1KAAYLrA== Content-Type: text/plain; charset="us-ascii" Content-ID: <9E4204906B1E2D4095AEFA2D8E970ADB@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:25:33 -0000 In order for that to work, the intermediary has to be authoritative for the number. =20 Would that work? Brian On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" wrote: >I assume the initial signing to be done by the endpoint, the pbx, which >has authority over the full E.164 number. > >If the canonical form is incorrect (the international format is incorrect >or the number is only provided in national format), I would have imagined >that the intermediary would have to provide a correct canonical form and >(?) resign. =20 > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, June 10, 2013 4:14 PM >To: FOUQUART Philippe OLNC/OLN >Cc: Rosen, Brian; stir@ietf.org >Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >middle boxes? > >I never thought about resigning. > >Whatever element signs has to be authoritative for the e.164. In your >example, who do you think would do the initial signing and who would >re-sign? > >Brian > >On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: > >> Thanks. Am I then right in rephrasing this as "it isn't going to be a >>problem if and only if the intermediary that corrects the canonical form >>is also able to [re]sign the [corrected] number?" >>=20 >> For CgPNs, I guess this would work for a pbx using numbers under ranges >>of their service provider (or ported to it), but may not easily work for >>(more interesting) cases where the CgPN is completely unrelated with the >>call centre that initiated the call (eg a concierge service using their >>customer's individual number, the "Permitted spoofing" case). >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 3:28 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>middle boxes? >>=20 >> If both the endpoints and their SPs understand the rules, then they can >>generate the signature and check it. >> Might have problems with intermediaries that couldn't do that unless >>the To was rewritten at some point. It would seem to me that in order >>to route these calls, that's what would have to happen unless you are >>using P-A-I passed between carriers to carry the decoded e.164. >>=20 >> Brian >>=20 >>=20 >> On Jun 10, 2013, at 9:06 AM, >> wrote: >>=20 >>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>pass end to end? >>>=20 >>> I'm not sure the following would fall into your category but in >>>addition to prefixing thaty's already been mentioned, you may also have >>>cases where the conversion from the dialing plan to the numbering plan >>>involves a "degree of complexity" that cannot be expected from some >>>endpoints because it is more complex than just "replace the national >>>prefix, aka 'trunk prefix', with the relevant geographic country code" >>>to get the full E.164 canonical form. (for example, supposing 0 as a >>>national trunk code, some dialing plans map 0-XXX to _several_ >>>geographic country codes +CC-XXX depending on the value of XXX). >>>=20 >>> One simple way to support these formats is to allow the endpoint (eg a >>>PBX) to always send +CC-XXX with one given CC (and therefore >>>potentially incorrect canonical form) and correct it with the right >>>mapping downstream. On may argue that it is a bit of a hack to make up >>>for the lack of support of a phone-context by the endpoints, but you >>>generally have to make do without it. >>>=20 >>> Regards, >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>Of Rosen, Brian >>> Sent: Friday, June 07, 2013 7:20 PM >>> To: stir@ietf.org >>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>middle boxes? >>>=20 >>> The fundamental idea that we have here is that you sign a set of >>>information with a credential, and you pass the signature and a pointer >>>to the credential in SIP signaling. >>>=20 >>> We have some disagreements about what is signed. >>>=20 >>> Henning has proposed that we canonicalize the From and To phone >>>numbers, we include a timestamp and some form of call-id, possibly the >>>INSIPID id. =20 >>>=20 >>> There are assertions that you can't use From/To, because middle boxes >>>change them. Some have suggested using P-A-I and other headers instead. >>>=20 >>> Hadriel wrote a draft about why From and To get modified: >>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>=20 >>> After reading it, I am unclear if a canonicalized e.164 would make it >>>through. The reasons given seem to indicate they would. They change >>>domains, they change prefixes, but they don't seem to change the actual >>>telephone number. >>>=20 >>> Can we come up with examples where a canonicalized e.164 would NOT >>>pass end to end? >>>=20 >>> Brian >>>=20 >>>=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, >>> France Telecom - 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, France Telecom - Orange is not liable for >>>messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >>=20 >>=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, >> France Telecom - 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, France Telecom - Orange is not liable for >>messages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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, >France Telecom - 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, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > From timothy.dwight@verizon.com Mon Jun 10 08:40: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 1A8F221F96A9 for ; Mon, 10 Jun 2013 08:40:00 -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=[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 fm31dijDQuPb for ; Mon, 10 Jun 2013 08:39:54 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D74321F9631 for ; Mon, 10 Jun 2013 08:39:54 -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; 10 Jun 2013 15:39:52 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,837,1363132800"; d="scan'208";a="486315522" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 10 Jun 2013 15:39:52 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 10 Jun 2013 11:39:52 -0400 To: "philippe.fouquart@orange.com" , "Rosen, Brian" Date: Mon, 10 Jun 2013 11:39:50 -0400 Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTV92NE3ldI+k2ZlJ4diB8iI5kvCIiQgAAHCDA= Message-ID: <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:40:00 -0000 I suppose it's possible that both the service provider to which the number = was assigned by the numbering plan authority, and the 'user' to whom that s= ervice provider assigned it, may have access to the associated private key.= I am not comfortable with the security implications of that, though. And= (to Brian's subsequent question) I'm not sure it works in all configuratio= ns, particularly I'm thinking of one in which the entity to whom the number= was assigned by the numbering plan authority, not being the one providing = PSTN ingress/egress services to it. If you follow the goings-on in the US = FCC you're no doubt familiar with the recently-announced trial of that scen= ario. I wonder if we're trying to solve the wrong problem. There is already prec= edent for a 'user asserted' identity separate from a 'network asserted' ide= ntity. Could we use the same / similar mechanisms for both, but keep them = separate? Or is there some underlying assumption that were the FROM header= sufficiently trustworthy, there would be no further need for P-A-I? I think keeping them separate, at least might simplify the issues arising f= rom too many entities needing access to the same private key. As they say,= 3 people can keep a secret only if 2 are dead. Cheers, tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of phi= lippe.fouquart@orange.com Sent: Monday, June 10, 2013 10:04 AM To: Rosen, Brian Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? I assume the initial signing to be done by the endpoint, the pbx, which has= authority over the full E.164 number. If the canonical form is incorrect (the international format is incorrect o= r the number is only provided in national format), I would have imagined th= at the intermediary would have to provide a correct canonical form and (?) = resign. =20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, June 10, 2013 4:14 PM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? I never thought about resigning. Whatever element signs has to be authoritative for the e.164. In your exam= ple, who do you think would do the initial signing and who would re-sign? Brian On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: > Thanks. Am I then right in rephrasing this as "it isn't going to be a pro= blem if and only if the intermediary that corrects the canonical form is al= so able to [re]sign the [corrected] number?"=20 >=20 > For CgPNs, I guess this would work for a pbx using numbers under ranges o= f their service provider (or ported to it), but may not easily work for (mo= re interesting) cases where the CgPN is completely unrelated with the call = centre that initiated the call (eg a concierge service using their customer= 's individual number, the "Permitted spoofing" case).=20 >=20 > Regards, >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, June 10, 2013 3:28 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > If both the endpoints and their SPs understand the rules, then they can g= enerate the signature and check it. > Might have problems with intermediaries that couldn't do that unless the = To was rewritten at some point. It would seem to me that in order to rout= e these calls, that's what would have to happen unless you are using P-A-I = passed between carriers to carry the decoded e.164. >=20 > Brian >=20 >=20 > On Jun 10, 2013, at 9:06 AM, > wrote: >=20 >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>=20 >> I'm not sure the following would fall into your category but in addition= to prefixing thaty's already been mentioned, you may also have cases where= the conversion from the dialing plan to the numbering plan involves a "deg= ree of complexity" that cannot be expected from some endpoints because it i= s more complex than just "replace the national prefix, aka 'trunk prefix', = with the relevant geographic country code" to get the full E.164 canonical = form. (for example, supposing 0 as a national trunk code, some dialing plan= s map 0-XXX to _several_ geographic country codes +CC-XXX depending on the = value of XXX).=20 >>=20 >> One simple way to support these formats is to allow the endpoint (eg a P= BX) to always send +CC-XXX with one given CC (and therefore potentially inc= orrect canonical form) and correct it with the right mapping downstream. On= may argue that it is a bit of a hack to make up for the lack of support of= a phone-context by the endpoints, but you generally have to make do withou= t it.=20 >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Rosen, Brian >> Sent: Friday, June 07, 2013 7:20 PM >> To: stir@ietf.org >> Subject: [stir] Can canonical phone numbers survive SBCs and other middl= e boxes? >>=20 >> The fundamental idea that we have here is that you sign a set of informa= tion with a credential, and you pass the signature and a pointer to the cre= dential in SIP signaling.=20 >>=20 >> We have some disagreements about what is signed. >>=20 >> Henning has proposed that we canonicalize the From and To phone numbers,= we include a timestamp and some form of call-id, possibly the INSIPID id. = =20 >>=20 >> There are assertions that you can't use From/To, because middle boxes ch= ange them. Some have suggested using P-A-I and other headers instead. >>=20 >> Hadriel wrote a draft about why From and To get modified: >> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>=20 >> After reading it, I am unclear if a canonicalized e.164 would make it th= rough. The reasons given seem to indicate they would. They change domains= , they change prefixes, but they don't seem to change the actual telephone = number. >>=20 >> Can we come up with examples where a canonicalized e.164 would NOT pass = end to end? >>=20 >> Brian >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hgs@cs.columbia.edu Mon Jun 10 08:44: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 4748E21F93D4 for ; Mon, 10 Jun 2013 08:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 e9joj8L4-XBd for ; Mon, 10 Jun 2013 08:43:54 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8784821F8EDF for ; Mon, 10 Jun 2013 08:43:54 -0700 (PDT) Received: from [172.20.27.51] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5AFhqe9010240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Jun 2013 11:43:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: <2606ED2D-B6EF-43D1-A059-6923222118EF@brianrosen.net> Date: Mon, 10 Jun 2013 11:44:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0055AFC5-82E6-477B-B595-664C5BD8A78C@cs.columbia.edu> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <19A98645-C9F4-4BE3-AC07-19A81AD8AEFE@acmepacket.com> <51B2369F.807@alum.mit.edu> <6ACFDE91-2405-4A3D-921A-099856B0C5AC@cs.columbia.edu> <51B23FC3.6080002@alum.mit.edu> <51B25CC4.6040902@cs.tcd.ie> <023a01ce63d1$8c4f3940$a4edabc0$@shockey.us> <51B26886.8020000@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3A03DAA8B@ex2k10mb2.corp.yaanatech.com> <2606ED2D-B6EF-43D1-A059-6923222118EF@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "stir@ietf.org" , Michael Hammer , "pkyzivat@alum.mit.edu" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:44:06 -0000 Also, with new headers you still have the same or similar problem - if = you just insert a new block with its own set of numbers, the destination = has to compare the To (and maybe From) headers with that block, to make = sure that the numbers actually are the same. Otherwise, anybody could = just cut-and-paste a legitimate signed block with some random call. If = you can compare the identifiers, you could presumably used the original = one. The more identifiers you have, with overlapping definitions, the more = challenging it gets to figure out what they mean. On Jun 10, 2013, at 8:52 AM, Brian Rosen wrote: >> The current headers are too over-loaded with usages at this point to = be much >> help here. > We have a hypothesis that numbers going between service providers are = always convertible to e.164 programatically. If you have relevant = examples where that is not true, please send them. >=20 > I'd rather not have new headers if we can avoid it. >=20 From brian.rosen@neustar.biz Mon Jun 10 08:47: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 63EB921F96DF for ; Mon, 10 Jun 2013 08:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 fYdzS8o0Gf7W for ; Mon, 10 Jun 2013 08:47:20 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9E921F96A9 for ; Mon, 10 Jun 2013 08:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370879728; x=1686233302; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=iP2Fsb2KYy rNNIkuRL9P/bbmYMj4GLJm2Re0PLseKq4=; b=QhdWri6Yyo05COLYaPMCL8+f0x 3Wg+u8RwPCm/bEDR7GlzLfcfHer4sLwZ89PCdJmcq6ptdQb01vHnLoNJIVug== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26035930; Mon, 10 Jun 2013 11:55:27 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 11:47:16 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 11:47:13 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuAgAAJ9gCAAAINgA== Date: Mon, 10 Jun 2013 15:47:13 +0000 Message-ID: <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: sPguST1ZoqxHeB+JJLvu+g== Content-Type: text/plain; charset="us-ascii" Content-ID: <57C814B2D558084FBF851DDFECE7FAF2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:47:24 -0000 Well, the PBX would have a sub delegation from the SP with a narrower scope= . For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. I= t then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX cou= ld sign with its 1300-1399 cert and the SP could sign with it's 1000-1999 c= ert. Brian On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" wrote: > I suppose it's possible that both the service provider to which the numbe= r was assigned by the numbering plan authority, and the 'user' to whom that= service provider assigned it, may have access to the associated private ke= y. I am not comfortable with the security implications of that, though. A= nd (to Brian's subsequent question) I'm not sure it works in all configurat= ions, particularly I'm thinking of one in which the entity to whom the numb= er was assigned by the numbering plan authority, not being the one providin= g PSTN ingress/egress services to it. If you follow the goings-on in the U= S FCC you're no doubt familiar with the recently-announced trial of that sc= enario. >=20 > I wonder if we're trying to solve the wrong problem. There is already pr= ecedent for a 'user asserted' identity separate from a 'network asserted' i= dentity. Could we use the same / similar mechanisms for both, but keep the= m separate? Or is there some underlying assumption that were the FROM head= er sufficiently trustworthy, there would be no further need for P-A-I? >=20 > I think keeping them separate, at least might simplify the issues arising= from too many entities needing access to the same private key. As they sa= y, 3 people can keep a secret only if 2 are dead. >=20 > Cheers, >=20 > tim >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of p= hilippe.fouquart@orange.com > Sent: Monday, June 10, 2013 10:04 AM > To: Rosen, Brian > Cc: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > I assume the initial signing to be done by the endpoint, the pbx, which h= as authority over the full E.164 number. >=20 > If the canonical form is incorrect (the international format is incorrect= or the number is only provided in national format), I would have imagined = that the intermediary would have to provide a correct canonical form and (?= ) resign. =20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, June 10, 2013 4:14 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > I never thought about resigning. >=20 > Whatever element signs has to be authoritative for the e.164. In your ex= ample, who do you think would do the initial signing and who would re-sign? >=20 > Brian >=20 > On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >=20 >> Thanks. Am I then right in rephrasing this as "it isn't going to be a pr= oblem if and only if the intermediary that corrects the canonical form is a= lso able to [re]sign the [corrected] number?"=20 >>=20 >> For CgPNs, I guess this would work for a pbx using numbers under ranges = of their service provider (or ported to it), but may not easily work for (m= ore interesting) cases where the CgPN is completely unrelated with the call= centre that initiated the call (eg a concierge service using their custome= r's individual number, the "Permitted spoofing" case).=20 >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 3:28 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >> If both the endpoints and their SPs understand the rules, then they can = generate the signature and check it. >> Might have problems with intermediaries that couldn't do that unless the= To was rewritten at some point. It would seem to me that in order to rou= te these calls, that's what would have to happen unless you are using P-A-I= passed between carriers to carry the decoded e.164. >>=20 >> Brian >>=20 >>=20 >> On Jun 10, 2013, at 9:06 AM, >> wrote: >>=20 >>>> Can we come up with examples where a canonicalized e.164 would NOT pas= s end to end? >>>=20 >>> I'm not sure the following would fall into your category but in additio= n to prefixing thaty's already been mentioned, you may also have cases wher= e the conversion from the dialing plan to the numbering plan involves a "de= gree of complexity" that cannot be expected from some endpoints because it = is more complex than just "replace the national prefix, aka 'trunk prefix',= with the relevant geographic country code" to get the full E.164 canonical= form. (for example, supposing 0 as a national trunk code, some dialing pla= ns map 0-XXX to _several_ geographic country codes +CC-XXX depending on the= value of XXX).=20 >>>=20 >>> One simple way to support these formats is to allow the endpoint (eg a = PBX) to always send +CC-XXX with one given CC (and therefore potentially in= correct canonical form) and correct it with the right mapping downstream. O= n may argue that it is a bit of a hack to make up for the lack of support o= f a phone-context by the endpoints, but you generally have to make do witho= ut it.=20 >>>=20 >>> Regards, >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Rosen, Brian >>> Sent: Friday, June 07, 2013 7:20 PM >>> To: stir@ietf.org >>> Subject: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? >>>=20 >>> The fundamental idea that we have here is that you sign a set of inform= ation with a credential, and you pass the signature and a pointer to the cr= edential in SIP signaling.=20 >>>=20 >>> We have some disagreements about what is signed. >>>=20 >>> Henning has proposed that we canonicalize the From and To phone numbers= , we include a timestamp and some form of call-id, possibly the INSIPID id.= =20 >>>=20 >>> There are assertions that you can't use From/To, because middle boxes c= hange them. Some have suggested using P-A-I and other headers instead. >>>=20 >>> Hadriel wrote a draft about why From and To get modified: >>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>=20 >>> After reading it, I am unclear if a canonicalized e.164 would make it t= hrough. The reasons given seem to indicate they would. They change domain= s, they change prefixes, but they don't seem to change the actual telephone= number. >>>=20 >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>>=20 >>> Brian >>>=20 >>> _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, France Telecom - Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, France Telecom = - 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, us= ed 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From oej@edvina.net Mon Jun 10 08:54: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 9313021F8617 for ; Mon, 10 Jun 2013 08:54: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 b-Al1Z0fCe2C for ; Mon, 10 Jun 2013 08:54:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DC30721F8916 for ; Mon, 10 Jun 2013 08:54:08 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 3858B93C1AF; Mon, 10 Jun 2013 15:54:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 10 Jun 2013 17:54:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1503) Cc: "philippe.fouquart@orange.com" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 15:54:17 -0000 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : > In order for that to work, the intermediary has to be authoritative for > the number. > Would that work? Have we defined "authoritative" for a specific number? /O > > Brian > > > On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" > wrote: > >> I assume the initial signing to be done by the endpoint, the pbx, which >> has authority over the full E.164 number. >> >> If the canonical form is incorrect (the international format is incorrect >> or the number is only provided in national format), I would have imagined >> that the intermediary would have to provide a correct canonical form and >> (?) resign. >> >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 4:14 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >> middle boxes? >> >> I never thought about resigning. >> >> Whatever element signs has to be authoritative for the e.164. In your >> example, who do you think would do the initial signing and who would >> re-sign? >> >> Brian >> >> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >> >>> Thanks. Am I then right in rephrasing this as "it isn't going to be a >>> problem if and only if the intermediary that corrects the canonical form >>> is also able to [re]sign the [corrected] number?" >>> >>> For CgPNs, I guess this would work for a pbx using numbers under ranges >>> of their service provider (or ported to it), but may not easily work for >>> (more interesting) cases where the CgPN is completely unrelated with the >>> call centre that initiated the call (eg a concierge service using their >>> customer's individual number, the "Permitted spoofing" case). >>> >>> Regards, >>> >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 3:28 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>> middle boxes? >>> >>> If both the endpoints and their SPs understand the rules, then they can >>> generate the signature and check it. >>> Might have problems with intermediaries that couldn't do that unless >>> the To was rewritten at some point. It would seem to me that in order >>> to route these calls, that's what would have to happen unless you are >>> using P-A-I passed between carriers to carry the decoded e.164. >>> >>> Brian >>> >>> >>> On Jun 10, 2013, at 9:06 AM, >>> wrote: >>> >>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>> pass end to end? >>>> >>>> I'm not sure the following would fall into your category but in >>>> addition to prefixing thaty's already been mentioned, you may also have >>>> cases where the conversion from the dialing plan to the numbering plan >>>> involves a "degree of complexity" that cannot be expected from some >>>> endpoints because it is more complex than just "replace the national >>>> prefix, aka 'trunk prefix', with the relevant geographic country code" >>>> to get the full E.164 canonical form. (for example, supposing 0 as a >>>> national trunk code, some dialing plans map 0-XXX to _several_ >>>> geographic country codes +CC-XXX depending on the value of XXX). >>>> >>>> One simple way to support these formats is to allow the endpoint (eg a >>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>> potentially incorrect canonical form) and correct it with the right >>>> mapping downstream. On may argue that it is a bit of a hack to make up >>>> for the lack of support of a phone-context by the endpoints, but you >>>> generally have to make do without it. >>>> >>>> Regards, >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of Rosen, Brian >>>> Sent: Friday, June 07, 2013 7:20 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>> middle boxes? >>>> >>>> The fundamental idea that we have here is that you sign a set of >>>> information with a credential, and you pass the signature and a pointer >>>> to the credential in SIP signaling. >>>> >>>> We have some disagreements about what is signed. >>>> >>>> Henning has proposed that we canonicalize the From and To phone >>>> numbers, we include a timestamp and some form of call-id, possibly the >>>> INSIPID id. >>>> >>>> There are assertions that you can't use From/To, because middle boxes >>>> change them. Some have suggested using P-A-I and other headers instead. >>>> >>>> Hadriel wrote a draft about why From and To get modified: >>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>> >>>> After reading it, I am unclear if a canonicalized e.164 would make it >>>> through. The reasons given seem to indicate they would. They change >>>> domains, they change prefixes, but they don't seem to change the actual >>>> telephone number. >>>> >>>> Can we come up with examples where a canonicalized e.164 would NOT >>>> pass end to end? >>>> >>>> Brian >>>> >>>> >>>> ________________________________________________________________________ >>>> _________________________________________________ >>>> >>>> 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, >>>> France Telecom - 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>> >>> >>> >>> _________________________________________________________________________ >>> ________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>> messages electroniques etant susceptibles d'alteration, >>> France Telecom - 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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, >> France Telecom - 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, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Mon Jun 10 09:10: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 DD64C21F95DD for ; Mon, 10 Jun 2013 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 GwJ6sGElAQaX for ; Mon, 10 Jun 2013 09:10:50 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 864DE21F95D7 for ; Mon, 10 Jun 2013 09:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370880539; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=QPabetUJzr YJot3lPB6e8dHVI4PW4cDJU61r6JwKlpo=; b=qqsRV7NozaAyc2wph+qTLzuWtF xERhrhWqRy0smNC47URSMfg8V+caDjie31L5FtLronc9D87WLn1kgYumPhLw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19355248; Mon, 10 Jun 2013 12:08:58 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 12:10:45 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 12:10:39 -0400 From: "Rosen, Brian" To: "Olle E. Johansson" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABKAA Date: Mon, 10 Jun 2013 16:10:38 +0000 Message-ID: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: soqfx2aTQ3hsF3TuCxxovw== Content-Type: text/plain; charset="us-ascii" Content-ID: <68AED8AA94030F4DA1BD59130E1D4CFE@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:10:58 -0000 A proposal on the table is that the PKI for Telephone Numbers (TNs) follows= the TN delegation chain. The root of trust is the national regulator, or = some contractor to it. When numbers are delegated, a cert for that delegat= ion goes with it. Numbers can be subdelgated, certs with the sub delegatio= n follow. So you are "authoritative" for a number if you have been delegat= ed (or sub delegated) that number, and have the cert for it. Every country= has a delegation system for numbers. There is a complication with number portability that might cause a specific= number in a range to no longer be valid, but there are simple solutions to= that, depending on how a country implements number portability. Brian On Jun 10, 2013, at 11:54 AM, Olle E. Johansson wrote: >=20 > 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >=20 >> In order for that to work, the intermediary has to be authoritative for >> the number. =20 >> Would that work? > Have we defined "authoritative" for a specific number? >=20 > /O >>=20 >> Brian >>=20 >>=20 >> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >> wrote: >>=20 >>> I assume the initial signing to be done by the endpoint, the pbx, which >>> has authority over the full E.164 number. >>>=20 >>> If the canonical form is incorrect (the international format is incorre= ct >>> or the number is only provided in national format), I would have imagin= ed >>> that the intermediary would have to provide a correct canonical form an= d >>> (?) resign. =20 >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 4:14 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: Rosen, Brian; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>> middle boxes? >>>=20 >>> I never thought about resigning. >>>=20 >>> Whatever element signs has to be authoritative for the e.164. In your >>> example, who do you think would do the initial signing and who would >>> re-sign? >>>=20 >>> Brian >>>=20 >>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>=20 >>>> Thanks. Am I then right in rephrasing this as "it isn't going to be a >>>> problem if and only if the intermediary that corrects the canonical fo= rm >>>> is also able to [re]sign the [corrected] number?" >>>>=20 >>>> For CgPNs, I guess this would work for a pbx using numbers under range= s >>>> of their service provider (or ported to it), but may not easily work f= or >>>> (more interesting) cases where the CgPN is completely unrelated with t= he >>>> call centre that initiated the call (eg a concierge service using thei= r >>>> customer's individual number, the "Permitted spoofing" case). >>>>=20 >>>> Regards, >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 3:28 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>>> middle boxes? >>>>=20 >>>> If both the endpoints and their SPs understand the rules, then they ca= n >>>> generate the signature and check it. >>>> Might have problems with intermediaries that couldn't do that unless >>>> the To was rewritten at some point. It would seem to me that in orde= r >>>> to route these calls, that's what would have to happen unless you are >>>> using P-A-I passed between carriers to carry the decoded e.164. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Jun 10, 2013, at 9:06 AM, >>>> wrote: >>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>>> pass end to end? >>>>>=20 >>>>> I'm not sure the following would fall into your category but in >>>>> addition to prefixing thaty's already been mentioned, you may also ha= ve >>>>> cases where the conversion from the dialing plan to the numbering pla= n >>>>> involves a "degree of complexity" that cannot be expected from some >>>>> endpoints because it is more complex than just "replace the national >>>>> prefix, aka 'trunk prefix', with the relevant geographic country code= " >>>>> to get the full E.164 canonical form. (for example, supposing 0 as a >>>>> national trunk code, some dialing plans map 0-XXX to _several_ >>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>=20 >>>>> One simple way to support these formats is to allow the endpoint (eg = a >>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>> potentially incorrect canonical form) and correct it with the right >>>>> mapping downstream. On may argue that it is a bit of a hack to make u= p >>>>> for the lack of support of a phone-context by the endpoints, but you >>>>> generally have to make do without it. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>> Of Rosen, Brian >>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>> To: stir@ietf.org >>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>>> middle boxes? >>>>>=20 >>>>> The fundamental idea that we have here is that you sign a set of >>>>> information with a credential, and you pass the signature and a point= er >>>>> to the credential in SIP signaling. >>>>>=20 >>>>> We have some disagreements about what is signed. >>>>>=20 >>>>> Henning has proposed that we canonicalize the From and To phone >>>>> numbers, we include a timestamp and some form of call-id, possibly th= e >>>>> INSIPID id. =20 >>>>>=20 >>>>> There are assertions that you can't use From/To, because middle boxes >>>>> change them. Some have suggested using P-A-I and other headers inste= ad. >>>>>=20 >>>>> Hadriel wrote a draft about why From and To get modified: >>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>=20 >>>>> After reading it, I am unclear if a canonicalized e.164 would make it >>>>> through. The reasons given seem to indicate they would. They change >>>>> domains, they change prefixes, but they don't seem to change the actu= al >>>>> telephone number. >>>>>=20 >>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>> pass end to end? >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=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 ave= z >>>>> 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, >>>>> France Telecom - 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 an= d >>>>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>=20 >>>>=20 >>>>=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, >>>> France Telecom - Orange decline toute responsabilite si ce message a >>>> ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d >>>> 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=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 message= s >>> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a et= e >>> 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From hadriel.kaplan@oracle.com Mon Jun 10 09:12: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 C8EC121F9690 for ; Mon, 10 Jun 2013 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 TkTHoMO9JCoR for ; Mon, 10 Jun 2013 09:12:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 411DB21F9633 for ; Mon, 10 Jun 2013 09:12:28 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5AGCQ2h031528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 16:12:27 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 r5AGCPT7025875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 16:12:26 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 r5AGCPcF017223; Mon, 10 Jun 2013 16:12:25 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 09:12:25 -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: <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> Date: Mon, 10 Jun 2013 12:12:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03248354-9EDE-4CB8-95CB-DBF31A56BB58@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:12:34 -0000 That depends on how the cert model works. I don't think a = PBX/Enterprise would want a single cert that says its authoritative for = 1300-1399, because frequently Enterprises don't want all their = numbers/range publicized. So when they make a call from a number X, = that's all they want the callee to see/know-about. -hadriel On Jun 10, 2013, at 11:47 AM, "Rosen, Brian" = wrote: > Well, the PBX would have a sub delegation from the SP with a narrower = scope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to = ..1999. It then may have delegated +CC-NPA-NXX-1300 to 1399 to the = PBX. The PBX could sign with its 1300-1399 cert and the SP could sign = with it's 1000-1999 cert. > Brian From philippe.fouquart@orange.com Mon Jun 10 09:14: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 7C0E121F9701 for ; Mon, 10 Jun 2013 09:14:26 -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, 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 bayh1QY53gXv for ; Mon, 10 Jun 2013 09:14:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6821F9700 for ; Mon, 10 Jun 2013 09:14:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3DBC018C994; Mon, 10 Jun 2013 18:14:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 18206238074; Mon, 10 Jun 2013 18:14:19 +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; Mon, 10 Jun 2013 18:14:18 +0200 From: To: "Olle E. Johansson" , "Rosen, Brian" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTV92NE3ldI+k2ZlJ4diB8iI5kvCIiQ///nlgCAAAgJgIAAJWiw Date: Mon, 10 Jun 2013 16:14:17 +0000 Message-ID: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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.5.21.113319 Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:14:26 -0000 I guess this would be a good place to start.=20 For cases where that number has to go through the entity that operates the = intermediary, either because it was ported in or because it was assigned wi= thin a range of that entity, I can imagine it would have 'some authority' o= n the number depending indeed on how you define it.=20 However, for cases where for (arguably) good reasons relative to the servic= e (eg a call centre) that number may be any number provided by the customer= of that service, I don't see how it could. Im' not even advocating it shou= ld, given the generality of the case, I'm just saying such cases do exist, = which is where this thread started from.=20=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Olle E. Johansson [mailto:oej@edvina.net]=20 Sent: Monday, June 10, 2013 5:54 PM To: Rosen, Brian Cc: Olle E. Johansson; FOUQUART Philippe OLNC/OLN; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : > In order for that to work, the intermediary has to be authoritative for > the number.=20=20 > Would that work? Have we defined "authoritative" for a specific number? /O >=20 > Brian >=20 >=20 > On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" > wrote: >=20 >> I assume the initial signing to be done by the endpoint, the pbx, which >> has authority over the full E.164 number. >>=20 >> If the canonical form is incorrect (the international format is incorrect >> or the number is only provided in national format), I would have imagined >> that the intermediary would have to provide a correct canonical form and >> (?) resign.=20=20 >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 4:14 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >> middle boxes? >>=20 >> I never thought about resigning. >>=20 >> Whatever element signs has to be authoritative for the e.164. In your >> example, who do you think would do the initial signing and who would >> re-sign? >>=20 >> Brian >>=20 >> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>=20 >>> Thanks. Am I then right in rephrasing this as "it isn't going to be a >>> problem if and only if the intermediary that corrects the canonical form >>> is also able to [re]sign the [corrected] number?" >>>=20 >>> For CgPNs, I guess this would work for a pbx using numbers under ranges >>> of their service provider (or ported to it), but may not easily work for >>> (more interesting) cases where the CgPN is completely unrelated with the >>> call centre that initiated the call (eg a concierge service using their >>> customer's individual number, the "Permitted spoofing" case). >>>=20 >>> Regards, >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 3:28 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>> middle boxes? >>>=20 >>> If both the endpoints and their SPs understand the rules, then they can >>> generate the signature and check it. >>> Might have problems with intermediaries that couldn't do that unless >>> the To was rewritten at some point. It would seem to me that in order >>> to route these calls, that's what would have to happen unless you are >>> using P-A-I passed between carriers to carry the decoded e.164. >>>=20 >>> Brian >>>=20 >>>=20 >>> On Jun 10, 2013, at 9:06 AM, >>> wrote: >>>=20 >>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>> pass end to end? >>>>=20 >>>> I'm not sure the following would fall into your category but in >>>> addition to prefixing thaty's already been mentioned, you may also have >>>> cases where the conversion from the dialing plan to the numbering plan >>>> involves a "degree of complexity" that cannot be expected from some >>>> endpoints because it is more complex than just "replace the national >>>> prefix, aka 'trunk prefix', with the relevant geographic country code" >>>> to get the full E.164 canonical form. (for example, supposing 0 as a >>>> national trunk code, some dialing plans map 0-XXX to _several_ >>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>=20 >>>> One simple way to support these formats is to allow the endpoint (eg a >>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>> potentially incorrect canonical form) and correct it with the right >>>> mapping downstream. On may argue that it is a bit of a hack to make up >>>> for the lack of support of a phone-context by the endpoints, but you >>>> generally have to make do without it. >>>>=20 >>>> Regards, >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of Rosen, Brian >>>> Sent: Friday, June 07, 2013 7:20 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>> middle boxes? >>>>=20 >>>> The fundamental idea that we have here is that you sign a set of >>>> information with a credential, and you pass the signature and a pointer >>>> to the credential in SIP signaling. >>>>=20 >>>> We have some disagreements about what is signed. >>>>=20 >>>> Henning has proposed that we canonicalize the From and To phone >>>> numbers, we include a timestamp and some form of call-id, possibly the >>>> INSIPID id.=20=20 >>>>=20 >>>> There are assertions that you can't use From/To, because middle boxes >>>> change them. Some have suggested using P-A-I and other headers instea= d. >>>>=20 >>>> Hadriel wrote a draft about why From and To get modified: >>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>=20 >>>> After reading it, I am unclear if a canonicalized e.164 would make it >>>> through. The reasons given seem to indicate they would. They change >>>> domains, they change prefixes, but they don't seem to change the actual >>>> telephone number. >>>>=20 >>>> Can we come up with examples where a canonicalized e.164 would NOT >>>> pass end to end? >>>>=20 >>>> Brian >>>>=20 >>>>=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, >>>> France Telecom - 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>=20 >>>=20 >>>=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, >>> France Telecom - 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=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, >> France Telecom - 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, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 > _______________________________________________ > 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From oej@edvina.net Mon Jun 10 09:14: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 4498221F9702 for ; Mon, 10 Jun 2013 09:14:52 -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 7vQjeR2MrKzX for ; Mon, 10 Jun 2013 09:14:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 3286A21F8EBC for ; Mon, 10 Jun 2013 09:14:48 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C813593C1AF; Mon, 10 Jun 2013 16:14:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> Date: Mon, 10 Jun 2013 18:14:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <926D9807-0805-48EA-B855-D64C81C2750D@edvina.net> References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1503) Cc: "philippe.fouquart@orange.com" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:14:52 -0000 10 jun 2013 kl. 18:10 skrev "Rosen, Brian" : > A proposal on the table is that the PKI for Telephone Numbers (TNs) = follows the TN delegation chain. The root of trust is the national = regulator, or some contractor to it. When numbers are delegated, a cert = for that delegation goes with it. Numbers can be subdelgated, certs = with the sub delegation follow. So you are "authoritative" for a number = if you have been delegated (or sub delegated) that number, and have the = cert for it. Every country has a delegation system for numbers. Sounds like DNSsec for the enum domain. >=20 > There is a complication with number portability that might cause a = specific number in a range to no longer be valid, but there are simple = solutions to that, depending on how a country implements number = portability. Ok. Thank you for the clarification. /O >=20 > Brian >=20 > On Jun 10, 2013, at 11:54 AM, Olle E. Johansson = wrote: >=20 >>=20 >> 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >>=20 >>> In order for that to work, the intermediary has to be authoritative = for >>> the number. =20 >>> Would that work? >> Have we defined "authoritative" for a specific number? >>=20 >> /O >>>=20 >>> Brian >>>=20 >>>=20 >>> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >>> wrote: >>>=20 >>>> I assume the initial signing to be done by the endpoint, the pbx, = which >>>> has authority over the full E.164 number. >>>>=20 >>>> If the canonical form is incorrect (the international format is = incorrect >>>> or the number is only provided in national format), I would have = imagined >>>> that the intermediary would have to provide a correct canonical = form and >>>> (?) resign. =20 >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 4:14 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other >>>> middle boxes? >>>>=20 >>>> I never thought about resigning. >>>>=20 >>>> Whatever element signs has to be authoritative for the e.164. In = your >>>> example, who do you think would do the initial signing and who = would >>>> re-sign? >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>>=20 >>>>> Thanks. Am I then right in rephrasing this as "it isn't going to = be a >>>>> problem if and only if the intermediary that corrects the = canonical form >>>>> is also able to [re]sign the [corrected] number?" >>>>>=20 >>>>> For CgPNs, I guess this would work for a pbx using numbers under = ranges >>>>> of their service provider (or ported to it), but may not easily = work for >>>>> (more interesting) cases where the CgPN is completely unrelated = with the >>>>> call centre that initiated the call (eg a concierge service using = their >>>>> customer's individual number, the "Permitted spoofing" case). >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other >>>>> middle boxes? >>>>>=20 >>>>> If both the endpoints and their SPs understand the rules, then = they can >>>>> generate the signature and check it. >>>>> Might have problems with intermediaries that couldn't do that = unless >>>>> the To was rewritten at some point. It would seem to me that in = order >>>>> to route these calls, that's what would have to happen unless you = are >>>>> using P-A-I passed between carriers to carry the decoded e.164. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Jun 10, 2013, at 9:06 AM, >>>>> wrote: >>>>>=20 >>>>>>> Can we come up with examples where a canonicalized e.164 would = NOT >>>>>>> pass end to end? >>>>>>=20 >>>>>> I'm not sure the following would fall into your category but in >>>>>> addition to prefixing thaty's already been mentioned, you may = also have >>>>>> cases where the conversion from the dialing plan to the numbering = plan >>>>>> involves a "degree of complexity" that cannot be expected from = some >>>>>> endpoints because it is more complex than just "replace the = national >>>>>> prefix, aka 'trunk prefix', with the relevant geographic country = code" >>>>>> to get the full E.164 canonical form. (for example, supposing 0 = as a >>>>>> national trunk code, some dialing plans map 0-XXX to _several_ >>>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>>=20 >>>>>> One simple way to support these formats is to allow the endpoint = (eg a >>>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>>> potentially incorrect canonical form) and correct it with the = right >>>>>> mapping downstream. On may argue that it is a bit of a hack to = make up >>>>>> for the lack of support of a phone-context by the endpoints, but = you >>>>>> generally have to make do without it. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf >>>>>> Of Rosen, Brian >>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and = other >>>>>> middle boxes? >>>>>>=20 >>>>>> The fundamental idea that we have here is that you sign a set of >>>>>> information with a credential, and you pass the signature and a = pointer >>>>>> to the credential in SIP signaling. >>>>>>=20 >>>>>> We have some disagreements about what is signed. >>>>>>=20 >>>>>> Henning has proposed that we canonicalize the =46rom and To phone >>>>>> numbers, we include a timestamp and some form of call-id, = possibly the >>>>>> INSIPID id. =20 >>>>>>=20 >>>>>> There are assertions that you can't use From/To, because middle = boxes >>>>>> change them. Some have suggested using P-A-I and other headers = instead. >>>>>>=20 >>>>>> Hadriel wrote a draft about why =46rom and To get modified: >>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>>=20 >>>>>> After reading it, I am unclear if a canonicalized e.164 would = make it >>>>>> through. The reasons given seem to indicate they would. They = change >>>>>> domains, they change prefixes, but they don't seem to change the = actual >>>>>> telephone number. >>>>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would = NOT >>>>>> pass end to end? >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=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, >>>>>> France Telecom - 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, France Telecom - Orange is not liable = for >>>>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=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, >>>>> France Telecom - 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, France Telecom - Orange is not liable = for >>>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=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, >>>> France Telecom - 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=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 brian.rosen@neustar.biz Mon Jun 10 09:16: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 032A421F97E6 for ; Mon, 10 Jun 2013 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 jQjKmlj5-Z0e for ; Mon, 10 Jun 2013 09:16:10 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id F214721F9711 for ; Mon, 10 Jun 2013 09:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370880858; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=XCyiotJe+y wzLZXUUgIV45pGJKganNkwTPUTap+lZg4=; b=c+xZRXRSJzxGSl1SRaZvRvKaj8 FXxAWNElx5dtMItRlxA2XlKugPBHlG9k1wZ8E4fCPRV2A8YWVDEekvv+Gt2Q== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19355453; Mon, 10 Jun 2013 12:14:16 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 12:16:02 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 12:16:01 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuAgAAJ9gCAAAINgIAABwuAgAABAgA= Date: Mon, 10 Jun 2013 16:16:00 +0000 Message-ID: <4D14E49B-B1D4-4FCC-8749-E9AED32AFDCC@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <03248354-9EDE-4CB8-95CB-DBF31A56BB58@oracle.com> In-Reply-To: <03248354-9EDE-4CB8-95CB-DBF31A56BB58@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 2cc76yWm4bADA2j7N3d5Ww== Content-Type: text/plain; charset="us-ascii" Content-ID: <9FA30553C5965546A52DC13BFDB4A2F9@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:16:14 -0000 They could request individual certs from their upstream provider. It's jus= t bookkeeping. Brian On Jun 10, 2013, at 12:12 PM, Hadriel Kaplan wr= ote: >=20 > That depends on how the cert model works. I don't think a PBX/Enterprise= would want a single cert that says its authoritative for 1300-1399, becaus= e frequently Enterprises don't want all their numbers/range publicized. So= when they make a call from a number X, that's all they want the callee to = see/know-about. >=20 > -hadriel >=20 >=20 > On Jun 10, 2013, at 11:47 AM, "Rosen, Brian" wr= ote: >=20 >> Well, the PBX would have a sub delegation from the SP with a narrower sc= ope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. = It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX = could sign with its 1300-1399 cert and the SP could sign with it's 1000-199= 9 cert. >> Brian >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Mon Jun 10 09: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 757C921F86CA for ; Mon, 10 Jun 2013 09:23:49 -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 r4R2zp6ugidU for ; Mon, 10 Jun 2013 09:23:45 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2F19421F869F for ; Mon, 10 Jun 2013 09:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370881603; x=1686240145; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=2phhmQBKeW CAyXt8tvi93onKJVO/5+/zpMDXnXaSPkU=; b=PcMZIknPNVpsxnkzTf6oYKqjY0 ZK9oFnZgtgnw3jtb4w1oSU54BUMaFSYi51WEdBCtt5TcIy9iJk3XdOuZ+R7w== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24888753; Mon, 10 Jun 2013 12:26:42 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 12:22:58 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 12:22:53 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABaWAgAACZIA= Date: Mon, 10 Jun 2013 16:22:51 +0000 Message-ID: References: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: mRuN3cDQORillD32cxKixA== Content-Type: text/plain; charset="us-ascii" Content-ID: <23250B08FAB5AA498D77C8D1F820C9F2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:23:49 -0000 We agree that there are permitted instances of number spoofing. A call cen= ter calling on behalf of an enterprise could use the enterprise's numbers. That would have to be explicitly permitted, either by the enterprise giving= the call center a cert based on it's delegation, or the upstream service p= rovider doing it based on a request from the enterprise. Both of those loo= k like sub delegations. The other example is a doctor calling from his mobile but using his office = number as the From. Same answer - the doctor or his SP authorizes this use= . The fact that you sub delegated doesn't mean the upper level delegation is = not still authoritative. The SP can sign an a call from the enterprise, ev= en if the SP delegated numbers and gave the SP a cert for that delegation. Brian On Jun 10, 2013, at 12:14 PM, wrote: > I guess this would be a good place to start.=20 >=20 > For cases where that number has to go through the entity that operates th= e intermediary, either because it was ported in or because it was assigned = within a range of that entity, I can imagine it would have 'some authority'= on the number depending indeed on how you define it.=20 >=20 > However, for cases where for (arguably) good reasons relative to the serv= ice (eg a call centre) that number may be any number provided by the custom= er of that service, I don't see how it could. Im' not even advocating it sh= ould, given the generality of the case, I'm just saying such cases do exist= , which is where this thread started from. =20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Olle E. Johansson [mailto:oej@edvina.net]=20 > Sent: Monday, June 10, 2013 5:54 PM > To: Rosen, Brian > Cc: Olle E. Johansson; FOUQUART Philippe OLNC/OLN; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 >=20 > 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >=20 >> In order for that to work, the intermediary has to be authoritative for >> the number. =20 >> Would that work? > Have we defined "authoritative" for a specific number? >=20 > /O >>=20 >> Brian >>=20 >>=20 >> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >> wrote: >>=20 >>> I assume the initial signing to be done by the endpoint, the pbx, which >>> has authority over the full E.164 number. >>>=20 >>> If the canonical form is incorrect (the international format is incorre= ct >>> or the number is only provided in national format), I would have imagin= ed >>> that the intermediary would have to provide a correct canonical form an= d >>> (?) resign. =20 >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 4:14 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: Rosen, Brian; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>> middle boxes? >>>=20 >>> I never thought about resigning. >>>=20 >>> Whatever element signs has to be authoritative for the e.164. In your >>> example, who do you think would do the initial signing and who would >>> re-sign? >>>=20 >>> Brian >>>=20 >>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>=20 >>>> Thanks. Am I then right in rephrasing this as "it isn't going to be a >>>> problem if and only if the intermediary that corrects the canonical fo= rm >>>> is also able to [re]sign the [corrected] number?" >>>>=20 >>>> For CgPNs, I guess this would work for a pbx using numbers under range= s >>>> of their service provider (or ported to it), but may not easily work f= or >>>> (more interesting) cases where the CgPN is completely unrelated with t= he >>>> call centre that initiated the call (eg a concierge service using thei= r >>>> customer's individual number, the "Permitted spoofing" case). >>>>=20 >>>> Regards, >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 3:28 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>>> middle boxes? >>>>=20 >>>> If both the endpoints and their SPs understand the rules, then they ca= n >>>> generate the signature and check it. >>>> Might have problems with intermediaries that couldn't do that unless >>>> the To was rewritten at some point. It would seem to me that in orde= r >>>> to route these calls, that's what would have to happen unless you are >>>> using P-A-I passed between carriers to carry the decoded e.164. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Jun 10, 2013, at 9:06 AM, >>>> wrote: >>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>>> pass end to end? >>>>>=20 >>>>> I'm not sure the following would fall into your category but in >>>>> addition to prefixing thaty's already been mentioned, you may also ha= ve >>>>> cases where the conversion from the dialing plan to the numbering pla= n >>>>> involves a "degree of complexity" that cannot be expected from some >>>>> endpoints because it is more complex than just "replace the national >>>>> prefix, aka 'trunk prefix', with the relevant geographic country code= " >>>>> to get the full E.164 canonical form. (for example, supposing 0 as a >>>>> national trunk code, some dialing plans map 0-XXX to _several_ >>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>=20 >>>>> One simple way to support these formats is to allow the endpoint (eg = a >>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>> potentially incorrect canonical form) and correct it with the right >>>>> mapping downstream. On may argue that it is a bit of a hack to make u= p >>>>> for the lack of support of a phone-context by the endpoints, but you >>>>> generally have to make do without it. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>> Of Rosen, Brian >>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>> To: stir@ietf.org >>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>>> middle boxes? >>>>>=20 >>>>> The fundamental idea that we have here is that you sign a set of >>>>> information with a credential, and you pass the signature and a point= er >>>>> to the credential in SIP signaling. >>>>>=20 >>>>> We have some disagreements about what is signed. >>>>>=20 >>>>> Henning has proposed that we canonicalize the From and To phone >>>>> numbers, we include a timestamp and some form of call-id, possibly th= e >>>>> INSIPID id. =20 >>>>>=20 >>>>> There are assertions that you can't use From/To, because middle boxes >>>>> change them. Some have suggested using P-A-I and other headers inste= ad. >>>>>=20 >>>>> Hadriel wrote a draft about why From and To get modified: >>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>=20 >>>>> After reading it, I am unclear if a canonicalized e.164 would make it >>>>> through. The reasons given seem to indicate they would. They change >>>>> domains, they change prefixes, but they don't seem to change the actu= al >>>>> telephone number. >>>>>=20 >>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>> pass end to end? >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=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 ave= z >>>>> 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, >>>>> France Telecom - 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 an= d >>>>> delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for >>>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>=20 >>>>=20 >>>>=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, >>>> France Telecom - Orange decline toute responsabilite si ce message a >>>> ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d >>>> 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=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 message= s >>> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a et= e >>> 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jun 10 09:24: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 7D84C21F9675 for ; Mon, 10 Jun 2013 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 JiPxfRjpMh4m for ; Mon, 10 Jun 2013 09:24:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F25A321F8EF2 for ; Mon, 10 Jun 2013 09:24:29 -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 r5AGNmuS011007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 16:23:49 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 r5AGNnF6017746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 16:23:49 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 r5AGNm51001152; Mon, 10 Jun 2013 16:23:48 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 09:23:48 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Mon, 10 Jun 2013 12:23:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Rosen, Brian" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:24:36 -0000 On Jun 10, 2013, at 12:14 PM, wrote: > However, for cases where for (arguably) good reasons relative to the = service (eg a call centre) that number may be any number provided by the = customer of that service, I don't see how it could. Im' not even = advocating it should, given the generality of the case, I'm just saying = such cases do exist, which is where this thread started from. =20 If the certificate-for-a-number model is used, then in theory the = customer of the service provides the call center with its private key to = sign outbound calls of its number. (or more likely, its service provider = would need to do it) -hadriel From hgs@cs.columbia.edu Mon Jun 10 09:28: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 B7FC921F84E7 for ; Mon, 10 Jun 2013 09:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 rtgECzsdZexx for ; Mon, 10 Jun 2013 09:28:24 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id C22A321F9644 for ; Mon, 10 Jun 2013 09:28:20 -0700 (PDT) Received: from [172.20.27.51] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5AGRxwE022718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Jun 2013 12:28:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: Date: Mon, 10 Jun 2013 12:28:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38DF4F14-54CE-4BD8-9B8C-0DD19585C3A1@cs.columbia.edu> References: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: philippe.fouquart@orange.com, "Olle E. Johansson" , "stir@ietf.org" , "Rosen, Brian" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:28:29 -0000 Or, as discussed, there are two entries in the database for the same = number, one for the assignee (call center customer) and one for the call = center, each with the respective private keys. Thus, no need for the = customer (assignee) to reveal its private key to the call center. On Jun 10, 2013, at 12:23 PM, Hadriel Kaplan = wrote: >=20 > On Jun 10, 2013, at 12:14 PM, wrote: >=20 >> However, for cases where for (arguably) good reasons relative to the = service (eg a call centre) that number may be any number provided by the = customer of that service, I don't see how it could. Im' not even = advocating it should, given the generality of the case, I'm just saying = such cases do exist, which is where this thread started from. =20 >=20 > If the certificate-for-a-number model is used, then in theory the = customer of the service provides the call center with its private key to = sign outbound calls of its number. (or more likely, its service provider = would need to do it) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From brian.rosen@neustar.biz Mon Jun 10 09:30: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 C523221F85E6 for ; Mon, 10 Jun 2013 09:30:13 -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.120, 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 iJOWJVQoUMHX for ; Mon, 10 Jun 2013 09:30:09 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91FD821F9385 for ; Mon, 10 Jun 2013 09:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370881698; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=H3h0vhlDbq MzGIUL40jYxEvywrdm7R81yqZg4E5HgPU=; b=EumZNLAOOG5spsoFYt5LHD6U/x VcsZqbtTLbAkenEQA1Yz+DZwmC0wqpvsuJsP48KmPxHRk1b7oj+B2bOBr/wQ== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19356190; Mon, 10 Jun 2013 12:28:16 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 12:30:03 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 12:29:57 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABaWAgAACpgCAAAG5AA== Date: Mon, 10 Jun 2013 16:29:57 +0000 Message-ID: References: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +mGcumMY8LH9mLTPGKqDQg== Content-Type: text/plain; charset="us-ascii" Content-ID: <25ECE42429368B458565B309F198EA90@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:30:14 -0000 The customer, if it has a cert, can issue a cert to the call center. It do= esn't have to share it's private key. Brian On Jun 10, 2013, at 12:23 PM, Hadriel Kaplan wr= ote: >=20 > On Jun 10, 2013, at 12:14 PM, wrote: >=20 >> However, for cases where for (arguably) good reasons relative to the ser= vice (eg a call centre) that number may be any number provided by the custo= mer of that service, I don't see how it could. Im' not even advocating it s= hould, given the generality of the case, I'm just saying such cases do exis= t, which is where this thread started from. =20 >=20 > If the certificate-for-a-number model is used, then in theory the custome= r of the service provides the call center with its private key to sign outb= ound calls of its number. (or more likely, its service provider would need = to do it) >=20 > -hadriel >=20 From rlb@ipv.sx Mon Jun 10 09:38: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 1E58421F9622 for ; Mon, 10 Jun 2013 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 TtHcQlxRhVLD for ; Mon, 10 Jun 2013 09:38:12 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0BA21E804C for ; Mon, 10 Jun 2013 09:38:11 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so10323333obq.21 for ; Mon, 10 Jun 2013 09:38:11 -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=RKq7VG54oIIUWfmMmCs5gy29SEmEIgvWwl+NE6zt220=; b=SSMy2iuNQjBy+Z3tToZ5IIbgFfSqeTkv8hUufen/dwYPuHEkOUUc5dN3Lb9BoOc/B/ s+sd36D4OVOk6fOOREysbrstzsQyO/N3Hp5nrgKY6v5o4H0VyFtVksvMPAAEhRE9RPlX on4iD42m6roaylex/7H4MxpTonaVbbSwmdqQ9g2p5fzCX/+mdpatbvQiFNg7+cSXfsFX n9F/z+xE9cSBXKLmA0dCa/z37e1ktfzccOMBVZMHPirejnC2+qd6juJNvMpwv1SaBOHA RSakqM4pfi/uC/2KKjNPMq+aRGU95Va4uy7OBeAhy0hI1ZdSct5vaV03QNFMZ8LbzdfI kSqw== MIME-Version: 1.0 X-Received: by 10.60.39.165 with SMTP id q5mr8585890oek.109.1370882291024; Mon, 10 Jun 2013 09:38:11 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 09:38:10 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: References: Date: Mon, 10 Jun 2013 12:38:10 -0400 Message-ID: From: Richard Barnes To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=089e013cbeecfc50e404decf678b X-Gm-Message-State: ALoCoQl6SFuiznNf4yxsdUw6Uv2oLLXuohrJwvjOFpKBlYNmzBD6hF87jKYecYfh4Xv+40AAsrGU Cc: "stir@ietf.org" , Torrey Searle Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:38:16 -0000 --089e013cbeecfc50e404decf678b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The ante for RSA signatures is 256 bytes, for ECDSA signatures 32-48 bytes. A SHA-256 digest is 32 bytes long. So (1) RSA probably isn't feasible, and (2) with EC, you're talking 64-96 bytes. On Sun, Jun 9, 2013 at 9:59 AM, DOLLY, MARTIN C wrote: > Answer the question=85 I wrote the ISUP standard**** > > ** ** > > *From:* Torrey Searle [mailto:tsearle@sipstacks.com] > *Sent:* Sunday, June 09, 2013 9:55 AM > *To:* DOLLY, MARTIN C > *Cc:* stir@ietf.org > > *Subject:* Re: [stir] A 4474 that will work through SBCs > (generally/potentially)**** > > ** ** > > The only restriction is that length is encoded in one byte. So that mean= s > 255 bytes of data. As binary data is allowed, base64 encoding isn't need= ed > either.**** > > Torrey**** > > ** ** > > On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C wrote:**= * > * > > How many octets?**** > > **** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Torrey Searle > *Sent:* Sunday, June 09, 2013 7:06 AM > *To:* stir@ietf.org > *Subject:* Re: [stir] A 4474 that will work through SBCs > (generally/potentially)**** > > **** > > >I'm not sure I understand the logic here.**** > > >Why would we trust a "not-evil" bit coming in from SS7/ISUP?**** > > >Why wouldn't all pink carriers just start setting that bit?**** > > In the case of**** > > SIP->SS7->SIP **** > > Wouldn't it be interesting for the Calling SIP party to put a signed hash= **** > > of the called/calling number into A sip header, copy that into the SS7 Us= er-To-User**** > > Header and then put it back into a SIP header on the destination sip leg? > > That way the Destination SIP network only needs to trust the originating = sip**** > > network and not any intermediate SS7 networks.**** > > Regards, > Torrey**** > > ** ** > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --089e013cbeecfc50e404decf678b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The ante for RSA signatures is 256 bytes, for ECDSA signat= ures 32-48 bytes. =A0A SHA-256 digest is 32 bytes long. =A0So (1) RSA proba= bly isn't feasible, and (2) with EC, you're talking 64-96 bytes.


On Sun, Jun 9= , 2013 at 9:59 AM, DOLLY, MARTIN C <md3135@att.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Answer the question=85 I = wrote the ISUP standard

=A0<= /p>

From: Torrey S= earle [mailto:ts= earle@sipstacks.com]
Sent: Sunday, June 09, 2013 9:55 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org=


Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

=A0

The only restriction = is that length is encoded in one byte.=A0 So that means 255 bytes of data.= =A0 As binary data is allowed, base64 encoding isn't needed either.<= /u>

Torrey

=A0

On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C <= md3135@att.com> = wrote:

How many octets?

=A0<= /p>

From: stir-bounces@iet= f.org [mailto:stir-bounces@ietf.org] On Behalf Of Torrey Searle
Sent: Sunday, June 09, 2013 7:06 AM
To: stir@ietf.org=
Subject: Re: [stir] A 4474 that will work through SBCs (generally/po= tentially)

=A0

>I'm not sure I understand the logic here.
>Why would we trust a "not-evil" bit coming in from SS7/I=
SUP?
>Why wouldn't all pink carriers =
just start setting that bit?
In the case of
SIP->SS7->SIP=A0 

Wouldn't it be interesting for the =
Calling SIP party to put a signed hash


of the called/calling number into A sip header, copy that into the SS7=
 User-To-User


Header and then put it back into a SIP =
header on the destination sip leg?

That way the Destination SIP netw=
ork only needs to trust the originating sip


network and not any intermediate SS7 ne=
tworks.


Regards,
Torrey

=A0


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


--089e013cbeecfc50e404decf678b-- From timothy.dwight@verizon.com Mon Jun 10 09:42: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 DC1D921F992B for ; Mon, 10 Jun 2013 09:42:21 -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=[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 t3XlyWxSGWMA for ; Mon, 10 Jun 2013 09:42:16 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE421F992E for ; Mon, 10 Jun 2013 09:42:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 10 Jun 2013 16:42:10 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,838,1363132800"; d="scan'208";a="486380987" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 10 Jun 2013 16:42:09 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 10 Jun 2013 12:42:09 -0400 To: "Rosen, Brian" Date: Mon, 10 Jun 2013 12:42:07 -0400 Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuAgAAJ9gCAAAINgP//v1IA Message-ID: <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> In-Reply-To: <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> 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: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:42:22 -0000 I guess that works as long as the number blocks are different, and it's cle= ar to the recipient whose public key he needs to use (the SP's or that of t= he PBX). How would he know? Trial and error? Also I don't know that it works in the "Vonage" scenario I referenced obliq= uely below. Tim -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Monday, June 10, 2013 10:47 AM To: Dwight, Timothy M (Tim) Cc: philippe.fouquart@orange.com; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? Well, the PBX would have a sub delegation from the SP with a narrower scope= . For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. I= t then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX cou= ld sign with its 1300-1399 cert and the SP could sign with it's 1000-1999 c= ert. Brian On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" wrote: > I suppose it's possible that both the service provider to which the numbe= r was assigned by the numbering plan authority, and the 'user' to whom that= service provider assigned it, may have access to the associated private ke= y. I am not comfortable with the security implications of that, though. A= nd (to Brian's subsequent question) I'm not sure it works in all configurat= ions, particularly I'm thinking of one in which the entity to whom the numb= er was assigned by the numbering plan authority, not being the one providin= g PSTN ingress/egress services to it. If you follow the goings-on in the U= S FCC you're no doubt familiar with the recently-announced trial of that sc= enario. >=20 > I wonder if we're trying to solve the wrong problem. There is already pr= ecedent for a 'user asserted' identity separate from a 'network asserted' i= dentity. Could we use the same / similar mechanisms for both, but keep the= m separate? Or is there some underlying assumption that were the FROM head= er sufficiently trustworthy, there would be no further need for P-A-I? >=20 > I think keeping them separate, at least might simplify the issues arising= from too many entities needing access to the same private key. As they sa= y, 3 people can keep a secret only if 2 are dead. >=20 > Cheers, >=20 > tim >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of philippe.fouquart@orange.com > Sent: Monday, June 10, 2013 10:04 AM > To: Rosen, Brian > Cc: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > I assume the initial signing to be done by the endpoint, the pbx, which h= as authority over the full E.164 number. >=20 > If the canonical form is incorrect (the international format is incorrect= or the number is only provided in national format), I would have imagined = that the intermediary would have to provide a correct canonical form and (?= ) resign. =20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, June 10, 2013 4:14 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > I never thought about resigning. >=20 > Whatever element signs has to be authoritative for the e.164. In your ex= ample, who do you think would do the initial signing and who would re-sign? >=20 > Brian >=20 > On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >=20 >> Thanks. Am I then right in rephrasing this as "it isn't going to be a pr= oblem if and only if the intermediary that corrects the canonical form is a= lso able to [re]sign the [corrected] number?"=20 >>=20 >> For CgPNs, I guess this would work for a pbx using numbers under ranges = of their service provider (or ported to it), but may not easily work for (m= ore interesting) cases where the CgPN is completely unrelated with the call= centre that initiated the call (eg a concierge service using their custome= r's individual number, the "Permitted spoofing" case).=20 >>=20 >> Regards, >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 3:28 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >> If both the endpoints and their SPs understand the rules, then they can = generate the signature and check it. >> Might have problems with intermediaries that couldn't do that unless the= To was rewritten at some point. It would seem to me that in order to rou= te these calls, that's what would have to happen unless you are using P-A-I= passed between carriers to carry the decoded e.164. >>=20 >> Brian >>=20 >>=20 >> On Jun 10, 2013, at 9:06 AM, >> wrote: >>=20 >>>> Can we come up with examples where a canonicalized e.164 would NOT pas= s end to end? >>>=20 >>> I'm not sure the following would fall into your category but in additio= n to prefixing thaty's already been mentioned, you may also have cases wher= e the conversion from the dialing plan to the numbering plan involves a "de= gree of complexity" that cannot be expected from some endpoints because it = is more complex than just "replace the national prefix, aka 'trunk prefix',= with the relevant geographic country code" to get the full E.164 canonical= form. (for example, supposing 0 as a national trunk code, some dialing pla= ns map 0-XXX to _several_ geographic country codes +CC-XXX depending on the= value of XXX).=20 >>>=20 >>> One simple way to support these formats is to allow the endpoint (eg a = PBX) to always send +CC-XXX with one given CC (and therefore potentially in= correct canonical form) and correct it with the right mapping downstream. O= n may argue that it is a bit of a hack to make up for the lack of support o= f a phone-context by the endpoints, but you generally have to make do witho= ut it.=20 >>>=20 >>> Regards, >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>> Of Rosen, Brian >>> Sent: Friday, June 07, 2013 7:20 PM >>> To: stir@ietf.org >>> Subject: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes? >>>=20 >>> The fundamental idea that we have here is that you sign a set of inform= ation with a credential, and you pass the signature and a pointer to the cr= edential in SIP signaling.=20 >>>=20 >>> We have some disagreements about what is signed. >>>=20 >>> Henning has proposed that we canonicalize the From and To phone numbers= , we include a timestamp and some form of call-id, possibly the INSIPID id.= =20 >>>=20 >>> There are assertions that you can't use From/To, because middle boxes c= hange them. Some have suggested using P-A-I and other headers instead. >>>=20 >>> Hadriel wrote a draft about why From and To get modified: >>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>=20 >>> After reading it, I am unclear if a canonicalized e.164 would make it t= hrough. The reasons given seem to indicate they would. They change domain= s, they change prefixes, but they don't seem to change the actual telephone= number. >>>=20 >>> Can we come up with examples where a canonicalized e.164 would NOT pass= end to end? >>>=20 >>> Brian >>>=20 >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, France Telecom - Orange decline toute responsabilite si c= e message a ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, France Telecom = - 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, us= ed 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Mon Jun 10 09:48: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 42DE521F88D8 for ; Mon, 10 Jun 2013 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 NOWura0q+cQk for ; Mon, 10 Jun 2013 09:48: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 5F15121F9452 for ; Mon, 10 Jun 2013 09:48:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 416F4BE62; Mon, 10 Jun 2013 17:47:57 +0100 (IST) 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 dQWem0SoeHqG; Mon, 10 Jun 2013 17:47:57 +0100 (IST) Received: from [IPv6:2001:770:10:203:f832:498d:bfde:d78a] (unknown [IPv6:2001:770:10:203:f832:498d:bfde:d78a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1DFBABE5C; Mon, 10 Jun 2013 17:47:57 +0100 (IST) Message-ID: <51B6033D.1010106@cs.tcd.ie> Date: Mon, 10 Jun 2013 17:47:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Barnes References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Torrey Searle Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:48:25 -0000 On 06/10/2013 05:38 PM, Richard Barnes wrote: > The ante for RSA signatures is 256 bytes, for ECDSA signatures 32-48 bytes. > A SHA-256 digest is 32 bytes long. So (1) RSA probably isn't feasible, > and (2) with EC, you're talking 64-96 bytes. ...and (2) comes with IPR fun/FUD of course. RSA and EC also have slightly different performance characteristics that sometimes (but maybe not here) need to be considered. Just noting that since I'm not sure if this community are familiar with those issues - participants in the putative wg will need to consider stuff like that while thinking about what alg(s) to have as a MUST implement. (Which is down the road some way I guess.) S. > > > On Sun, Jun 9, 2013 at 9:59 AM, DOLLY, MARTIN C wrote: > >> Answer the question… I wrote the ISUP standard**** >> >> ** ** >> >> *From:* Torrey Searle [mailto:tsearle@sipstacks.com] >> *Sent:* Sunday, June 09, 2013 9:55 AM >> *To:* DOLLY, MARTIN C >> *Cc:* stir@ietf.org >> >> *Subject:* Re: [stir] A 4474 that will work through SBCs >> (generally/potentially)**** >> >> ** ** >> >> The only restriction is that length is encoded in one byte. So that means >> 255 bytes of data. As binary data is allowed, base64 encoding isn't needed >> either.**** >> >> Torrey**** >> >> ** ** >> >> On Sun, Jun 9, 2013 at 3:11 PM, DOLLY, MARTIN C wrote:*** >> * >> >> How many octets?**** >> >> **** >> >> *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf >> Of *Torrey Searle >> *Sent:* Sunday, June 09, 2013 7:06 AM >> *To:* stir@ietf.org >> *Subject:* Re: [stir] A 4474 that will work through SBCs >> (generally/potentially)**** >> >> **** >> >>> I'm not sure I understand the logic here.**** >> >>> Why would we trust a "not-evil" bit coming in from SS7/ISUP?**** >> >>> Why wouldn't all pink carriers just start setting that bit?**** >> >> In the case of**** >> >> SIP->SS7->SIP **** >> >> Wouldn't it be interesting for the Calling SIP party to put a signed hash**** >> >> of the called/calling number into A sip header, copy that into the SS7 User-To-User**** >> >> Header and then put it back into a SIP header on the destination sip leg? >> >> That way the Destination SIP network only needs to trust the originating sip**** >> >> network and not any intermediate SS7 networks.**** >> >> Regards, >> Torrey**** >> >> ** ** >> >> _______________________________________________ >> 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 Mon Jun 10 09:51: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 836B721F96C2 for ; Mon, 10 Jun 2013 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ZkQBblDx6wWN for ; Mon, 10 Jun 2013 09:51:28 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2268E21F95D7 for ; Mon, 10 Jun 2013 09:51:28 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so10435127obb.1 for ; Mon, 10 Jun 2013 09:51:27 -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=KbWfuN1jA4jptAfiVQLZDxLHLi7FmyP12pnzmuuPIBo=; b=pwjZ9XBeQri1dr9GHCCQWev4hOA4ok5A3nfVYYezy9QJrPiOhY+c86bWekOyXsajrj BSXK7JoK1UHxWRsgCoWyDya6WFIBGjAnPB7vVW4iWFJHTZwVMwoysq6eOMKcwJhLLcw5 XszkU88e1FRlIcEsbsdPS/ruekXRMjriF6LqZfjcuHoEFxbwrJgXf+FsK1Yt0p+07ig1 fZZoWZPPzHGgPG0Wsn6n79VLTeq2tNcktCWF+3mfiqgoNFXDT/h1L8jzAhnxFY9Scb+D GsuoanJOAduoAYCofWMjs561scIH6cgZw3REuEa+P18w4GGXslgPXm2xJcSSPn7VrLcs PQbA== MIME-Version: 1.0 X-Received: by 10.60.43.232 with SMTP id z8mr8594551oel.138.1370883087560; Mon, 10 Jun 2013 09:51:27 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 09:51:27 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> Date: Mon, 10 Jun 2013 12:51:27 -0400 Message-ID: From: Richard Barnes To: "Dwight, Timothy M (Tim)" Content-Type: multipart/alternative; boundary=001a113311fc76805b04decf979b X-Gm-Message-State: ALoCoQmuONER9biQ6JN24d6m2fxoeEhwwyH298DvyJwBUXkVrvFzZXcyEkIgLAFXIpccwKIuprXz Cc: "Rosen, Brian" , "stir@ietf.org" , "philippe.fouquart@orange.com" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:51:33 -0000 --001a113311fc76805b04decf979b Content-Type: text/plain; charset=ISO-8859-1 The traditional approach is that a signed object carries an identifier for the key that should be used to verify it, e.g., a hash of the public key. This is done in PKIX, S/MIME, JOSE, ... --Richard On Mon, Jun 10, 2013 at 12:42 PM, Dwight, Timothy M (Tim) < timothy.dwight@verizon.com> wrote: > I guess that works as long as the number blocks are different, and it's > clear to the recipient whose public key he needs to use (the SP's or that > of the PBX). How would he know? Trial and error? > > Also I don't know that it works in the "Vonage" scenario I referenced > obliquely below. > > Tim > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, June 10, 2013 10:47 AM > To: Dwight, Timothy M (Tim) > Cc: philippe.fouquart@orange.com; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > Well, the PBX would have a sub delegation from the SP with a narrower > scope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to > ..1999. It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. > The PBX could sign with its 1300-1399 cert and the SP could sign with it's > 1000-1999 cert. > > Brian > > On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" < > timothy.dwight@verizon.com> > wrote: > > > I suppose it's possible that both the service provider to which the > number was assigned by the numbering plan authority, and the 'user' to whom > that service provider assigned it, may have access to the associated > private key. I am not comfortable with the security implications of that, > though. And (to Brian's subsequent question) I'm not sure it works in all > configurations, particularly I'm thinking of one in which the entity to > whom the number was assigned by the numbering plan authority, not being the > one providing PSTN ingress/egress services to it. If you follow the > goings-on in the US FCC you're no doubt familiar with the > recently-announced trial of that scenario. > > > > I wonder if we're trying to solve the wrong problem. There is already > precedent for a 'user asserted' identity separate from a 'network asserted' > identity. Could we use the same / similar mechanisms for both, but keep > them separate? Or is there some underlying assumption that were the FROM > header sufficiently trustworthy, there would be no further need for P-A-I? > > > > I think keeping them separate, at least might simplify the issues > arising from too many entities needing access to the same private key. As > they say, 3 people can keep a secret only if 2 are dead. > > > > Cheers, > > > > tim > > > > > > > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > > Of philippe.fouquart@orange.com > > Sent: Monday, June 10, 2013 10:04 AM > > To: Rosen, Brian > > Cc: stir@ietf.org > > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > I assume the initial signing to be done by the endpoint, the pbx, which > has authority over the full E.164 number. > > > > If the canonical form is incorrect (the international format is > incorrect or the number is only provided in national format), I would have > imagined that the intermediary would have to provide a correct canonical > form and (?) resign. > > > > Philippe Fouquart > > Orange Labs Networks > > +33 (0) 1 45 29 58 13 > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Monday, June 10, 2013 4:14 PM > > To: FOUQUART Philippe OLNC/OLN > > Cc: Rosen, Brian; stir@ietf.org > > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > > > > I never thought about resigning. > > > > Whatever element signs has to be authoritative for the e.164. In your > example, who do you think would do the initial signing and who would > re-sign? > > > > Brian > > > > On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: > > > >> Thanks. Am I then right in rephrasing this as "it isn't going to be a > problem if and only if the intermediary that corrects the canonical form is > also able to [re]sign the [corrected] number?" > >> > >> For CgPNs, I guess this would work for a pbx using numbers under ranges > of their service provider (or ported to it), but may not easily work for > (more interesting) cases where the CgPN is completely unrelated with the > call centre that initiated the call (eg a concierge service using their > customer's individual number, the "Permitted spoofing" case). > >> > >> Regards, > >> > >> Philippe Fouquart > >> Orange Labs Networks > >> +33 (0) 1 45 29 58 13 > >> > >> > >> -----Original Message----- > >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >> Sent: Monday, June 10, 2013 3:28 PM > >> To: FOUQUART Philippe OLNC/OLN > >> Cc: stir@ietf.org > >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > >> > >> If both the endpoints and their SPs understand the rules, then they can > generate the signature and check it. > >> Might have problems with intermediaries that couldn't do that unless > the To was rewritten at some point. It would seem to me that in order to > route these calls, that's what would have to happen unless you are using > P-A-I passed between carriers to carry the decoded e.164. > >> > >> Brian > >> > >> > >> On Jun 10, 2013, at 9:06 AM, > >> wrote: > >> > >>>> Can we come up with examples where a canonicalized e.164 would NOT > pass end to end? > >>> > >>> I'm not sure the following would fall into your category but in > addition to prefixing thaty's already been mentioned, you may also have > cases where the conversion from the dialing plan to the numbering plan > involves a "degree of complexity" that cannot be expected from some > endpoints because it is more complex than just "replace the national > prefix, aka 'trunk prefix', with the relevant geographic country code" to > get the full E.164 canonical form. (for example, supposing 0 as a national > trunk code, some dialing plans map 0-XXX to _several_ geographic country > codes +CC-XXX depending on the value of XXX). > >>> > >>> One simple way to support these formats is to allow the endpoint (eg a > PBX) to always send +CC-XXX with one given CC (and therefore potentially > incorrect canonical form) and correct it with the right mapping downstream. > On may argue that it is a bit of a hack to make up for the lack of support > of a phone-context by the endpoints, but you generally have to make do > without it. > >>> > >>> Regards, > >>> > >>> Philippe Fouquart > >>> Orange Labs Networks > >>> +33 (0) 1 45 29 58 13 > >>> > >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >>> Of Rosen, Brian > >>> Sent: Friday, June 07, 2013 7:20 PM > >>> To: stir@ietf.org > >>> Subject: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? > >>> > >>> The fundamental idea that we have here is that you sign a set of > information with a credential, and you pass the signature and a pointer to > the credential in SIP signaling. > >>> > >>> We have some disagreements about what is signed. > >>> > >>> Henning has proposed that we canonicalize the From and To phone > numbers, we include a timestamp and some form of call-id, possibly the > INSIPID id. > >>> > >>> There are assertions that you can't use From/To, because middle boxes > change them. Some have suggested using P-A-I and other headers instead. > >>> > >>> Hadriel wrote a draft about why From and To get modified: > >>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt > >>> > >>> After reading it, I am unclear if a canonicalized e.164 would make it > through. The reasons given seem to indicate they would. They change > domains, they change prefixes, but they don't seem to change the actual > telephone number. > >>> > >>> Can we come up with examples where a canonicalized e.164 would NOT > pass end to end? > >>> > >>> Brian > >>> > >>> ____________________________________________________________________ > >>> _ ____________________________________________________ > >>> > >>> 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, France Telecom - 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, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >>> Thank you. > >>> > >> > >> > >> _____________________________________________________________________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, France Telecom - 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, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> 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, > France Telecom - 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, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > 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 > --001a113311fc76805b04decf979b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The traditional approach is that a signed object carries a= n identifier for the key that should be used to verify it, e.g., a hash of = the public key. =A0This is done in PKIX, S/MIME, JOSE, ...
--Richard


On Mon,= Jun 10, 2013 at 12:42 PM, Dwight, Timothy M (Tim) <timothy.dwigh= t@verizon.com> wrote:
I guess that works as long as the number blo= cks are different, and it's clear to the recipient whose public key he = needs to use (the SP's or that of the PBX). =A0How would he know? =A0Tr= ial and error?

Also I don't know that it works in the "Vonage" scenario I re= ferenced obliquely below.

Tim


-----Original Message-----
From: Rosen, Brian [mailto:Brian= .Rosen@neustar.biz]
Sent: Monday, June 10, 2013 10:47 AM
To: Dwight, Timothy M (Tim)
Cc: philippe.fouquart@orang= e.com; stir@ietf.org
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other midd= le boxes?

Well, the PBX would have a sub delegation from the SP with a narrower scope= . =A0For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. = =A0 It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. =A0The = PBX could sign with its 1300-1399 cert and the SP could sign with it's = 1000-1999 cert.

Brian

On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com>=
=A0wrote:

> I suppose it's possible that both the service provider to which th= e number was assigned by the numbering plan authority, and the 'user= 9; to whom that service provider assigned it, may have access to the associ= ated private key. =A0I am not comfortable with the security implications of= that, though. =A0And (to Brian's subsequent question) I'm not sure= it works in all configurations, particularly I'm thinking of one in wh= ich the entity to whom the number was assigned by the numbering plan author= ity, not being the one providing PSTN ingress/egress services to it. =A0If = you follow the goings-on in the US FCC you're no doubt familiar with th= e recently-announced trial of that scenario.
>
> I wonder if we're trying to solve the wrong problem. =A0There is a= lready precedent for a 'user asserted' identity separate from a = 9;network asserted' identity. =A0Could we use the same / similar mechan= isms for both, but keep them separate? =A0Or is there some underlying assum= ption that were the FROM header sufficiently trustworthy, there would be no= further need for P-A-I?
>
> I think keeping them separate, at least might simplify the issues aris= ing from too many entities needing access to the same private key. =A0As th= ey say, 3 people can keep a secret only if 2 are dead.
>
> Cheers,
>
> tim
>
>
>
> -----Original Message-----
> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf
> Of philippe.fouquart@o= range.com
> Sent: Monday, June 10, 2013 10:04 AM
> To: Rosen, Brian
> Cc: stir@ietf.org
> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other= middle boxes?
>
> I assume the initial signing to be done by the endpoint, the pbx, whic= h has authority over the full E.164 number.
>
> If the canonical form is incorrect (the international format is incorr= ect or the number is only provided in national format), I would have imagin= ed that the intermediary would have to provide a correct canonical form and= (?) resign.
>
> Philippe Fouquart
> Orange Labs Networks
> +33 (0) 1 45 29 58 13
>
>
> -----Original Message-----
> From: Rosen, Brian [mailto:= Brian.Rosen@neustar.biz]
> Sent: Monday, June 10, 2013 4:14 PM
> To: FOUQUART Philippe OLNC/OLN
> Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other= middle boxes?
>
> I never thought about resigning.
>
> Whatever element signs has to be authoritative for the e.164. =A0In yo= ur example, who do you think would do the initial signing and who would re-= sign?
>
> Brian
>
> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote:
>
>> Thanks. Am I then right in rephrasing this as "it isn't g= oing to be a problem if and only if the intermediary that corrects the cano= nical form is also able to [re]sign the [corrected] number?"
>>
>> For CgPNs, I guess this would work for a pbx using numbers under r= anges of their service provider (or ported to it), but may not easily work = for (more interesting) cases where the CgPN is completely unrelated with th= e call centre that initiated the call (eg a concierge service using their c= ustomer's individual number, the "Permitted spoofing" case).<= br> >>
>> Regards,
>>
>> Philippe Fouquart
>> Orange Labs Networks
>> +33 (0) 1 45 29 58 13
>>
>>
>> -----Original Message-----
>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
>> Sent: Monday, June 10, 2013 3:28 PM
>> To: FOUQUART Philippe OLNC/OLN
>> Cc: stir@ietf.org
>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and o= ther middle boxes?
>>
>> If both the endpoints and their SPs understand the rules, then the= y can generate the signature and check it.
>> Might have problems with intermediaries that couldn't do that = unless the To was rewritten at some point. =A0 It would seem to me that in = order to route these calls, that's what would have to happen unless you= are using P-A-I passed between carriers to carry the decoded e.164.
>>
>> Brian
>>
>>
>> On Jun 10, 2013, at 9:06 AM, <philippe.fouquart@orange.com>
>> wrote:
>>
>>>> Can we come up with examples where a canonicalized e.164 w= ould NOT pass end to end?
>>>
>>> I'm not sure the following would fall into your category b= ut in addition to prefixing thaty's already been mentioned, you may als= o have cases where the conversion from the dialing plan to the numbering pl= an involves a "degree of complexity" that cannot be expected from= some endpoints because it is more complex than just "replace the nati= onal prefix, aka 'trunk prefix', with the relevant geographic count= ry code" to get the full E.164 canonical form. (for example, supposing= 0 as a national trunk code, some dialing plans map 0-XXX to _several_ geog= raphic country codes +CC-XXX depending on the value of XXX).
>>>
>>> One simple way to support these formats is to allow the endpoi= nt (eg a PBX) to always send +CC-XXX with one given CC (and therefore poten= tially incorrect canonical form) and correct it with the right mapping down= stream. On may argue that it is a bit of a hack to make up for the lack of = support of a phone-context by the endpoints, but you generally have to make= do without it.
>>>
>>> Regards,
>>>
>>> Philippe Fouquart
>>> Orange Labs Networks
>>> +33 (0) 1 45 29 58 13
>>>
>>> From: stir-bounces@ie= tf.org [mailto:stir-bounces@ie= tf.org] On Behalf
>>> Of Rosen, Brian
>>> Sent: Friday, June 07, 2013 7:20 PM
>>> To: stir@ietf.org
>>> Subject: [stir] Can canonical phone numbers survive SBCs and o= ther middle boxes?
>>>
>>> The fundamental idea that we have here is that you sign a set = of information with a credential, and you pass the signature and a pointer = to the credential in SIP signaling.
>>>
>>> We have some disagreements about what is signed.
>>>
>>> Henning has proposed that we canonicalize the From and To phon= e numbers, we include a timestamp and some form of call-id, possibly the IN= SIPID id.
>>>
>>> There are assertions that you can't use From/To, because m= iddle boxes change them. =A0Some have suggested using P-A-I and other heade= rs instead.
>>>
>>> Hadriel wrote a draft about why From and To get modified:
>>> http://tools.ietf.org/id/draft-kaplan-sip-uris= -change-00.txt
>>>
>>> After reading it, I am unclear if a canonicalized e.164 would = make it through. =A0The reasons given seem to indicate they would. =A0They = change domains, they change prefixes, but they don't seem to change the= actual telephone number.
>>>
>>> Can we come up with examples where a canonicalized e.164 would= NOT pass end to end?
>>>
>>> Brian
>>>
>>> ______________________________________________________________= ______
>>> _ ________________________________________________= ____
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informat= ions
>>> 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 et= ant susceptibles d'alteration, France Telecom - Orange decline toute re= sponsabilite 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 shou= ld not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the se= nder and delete this message and its attachments.
>>> As emails may be altered, France Telecom - Orange is not liabl= e for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>
>>
>> __________________________________________________________________= ___
>> _ ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire= ainsi que les pieces jointes. Les messages electroniques etant susceptible= s d'alteration, France Telecom - 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 n= ot 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, France Telecom - Orange is not liable fo= r messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>
> ______________________________________________________________________=
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite= s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez le signaler a l'expediteur et le detruire ainsi que les pieces jo= intes. Les messages electroniques etant susceptibles d'alteration, Fran= ce Telecom - Orange decline toute responsabilite si ce message a ete altere= , deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d 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, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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

--001a113311fc76805b04decf979b-- From brian.rosen@neustar.biz Mon Jun 10 09:53: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 B6FB521F8EFE for ; Mon, 10 Jun 2013 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 GAUCrJyQKlMt for ; Mon, 10 Jun 2013 09:53:42 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3021F85EB for ; Mon, 10 Jun 2013 09:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370883402; x=1686240145; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=RnCP2VKHJp ZLAPX00007paxQ137RPx750JL19DYJdzo=; b=XD17BV4cV4/WO9lYyAqjSprnHv 6EF5MjPkcu6rTESbej3WBiJ9abAJU059rGv77NwSZHYGQGvLSq3c5J1Zp9BQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24890429; Mon, 10 Jun 2013 12:56:41 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 12:53:39 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 12:53:34 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuAgAAJ9gCAAAINgP//v1IAgABTOYA= Date: Mon, 10 Jun 2013 16:53:34 +0000 Message-ID: <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NXfBxRqt4ytWlKhBR82jYA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" , "philippe.fouquart@orange.com" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:53:47 -0000 The URI to the cert used for signing comes in the signaling. Some folks on the list have proposed to use P-Asserted-Identity instead of = From. Others want to be able to make the mechanism end to end (instead of = SP to SP) and would prefer to base the sig on From rather than P-A-I. Brian On Jun 10, 2013, at 12:42 PM, "Dwight, Timothy M \(Tim\)" wrote: > I guess that works as long as the number blocks are different, and it's c= lear to the recipient whose public key he needs to use (the SP's or that of= the PBX). How would he know? Trial and error? >=20 > Also I don't know that it works in the "Vonage" scenario I referenced obl= iquely below. >=20 > Tim >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Monday, June 10, 2013 10:47 AM > To: Dwight, Timothy M (Tim) > Cc: philippe.fouquart@orange.com; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? >=20 > Well, the PBX would have a sub delegation from the SP with a narrower sco= pe. For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. = It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX c= ould sign with its 1300-1399 cert and the SP could sign with it's 1000-1999= cert. >=20 > Brian >=20 > On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" > wrote: >=20 >> I suppose it's possible that both the service provider to which the numb= er was assigned by the numbering plan authority, and the 'user' to whom tha= t service provider assigned it, may have access to the associated private k= ey. I am not comfortable with the security implications of that, though. = And (to Brian's subsequent question) I'm not sure it works in all configura= tions, particularly I'm thinking of one in which the entity to whom the num= ber was assigned by the numbering plan authority, not being the one providi= ng PSTN ingress/egress services to it. If you follow the goings-on in the = US FCC you're no doubt familiar with the recently-announced trial of that s= cenario. >>=20 >> I wonder if we're trying to solve the wrong problem. There is already p= recedent for a 'user asserted' identity separate from a 'network asserted' = identity. Could we use the same / similar mechanisms for both, but keep th= em separate? Or is there some underlying assumption that were the FROM hea= der sufficiently trustworthy, there would be no further need for P-A-I? >>=20 >> I think keeping them separate, at least might simplify the issues arisin= g from too many entities needing access to the same private key. As they s= ay, 3 people can keep a secret only if 2 are dead. >>=20 >> Cheers, >>=20 >> tim >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of philippe.fouquart@orange.com >> Sent: Monday, June 10, 2013 10:04 AM >> To: Rosen, Brian >> Cc: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >> I assume the initial signing to be done by the endpoint, the pbx, which = has authority over the full E.164 number. >>=20 >> If the canonical form is incorrect (the international format is incorrec= t or the number is only provided in national format), I would have imagined= that the intermediary would have to provide a correct canonical form and (= ?) resign. =20 >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, June 10, 2013 4:14 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >> I never thought about resigning. >>=20 >> Whatever element signs has to be authoritative for the e.164. In your e= xample, who do you think would do the initial signing and who would re-sign= ? >>=20 >> Brian >>=20 >> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>=20 >>> Thanks. Am I then right in rephrasing this as "it isn't going to be a p= roblem if and only if the intermediary that corrects the canonical form is = also able to [re]sign the [corrected] number?"=20 >>>=20 >>> For CgPNs, I guess this would work for a pbx using numbers under ranges= of their service provider (or ported to it), but may not easily work for (= more interesting) cases where the CgPN is completely unrelated with the cal= l centre that initiated the call (eg a concierge service using their custom= er's individual number, the "Permitted spoofing" case).=20 >>>=20 >>> Regards, >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 3:28 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other = middle boxes? >>>=20 >>> If both the endpoints and their SPs understand the rules, then they can= generate the signature and check it. >>> Might have problems with intermediaries that couldn't do that unless th= e To was rewritten at some point. It would seem to me that in order to ro= ute these calls, that's what would have to happen unless you are using P-A-= I passed between carriers to carry the decoded e.164. >>>=20 >>> Brian >>>=20 >>>=20 >>> On Jun 10, 2013, at 9:06 AM, >>> wrote: >>>=20 >>>>> Can we come up with examples where a canonicalized e.164 would NOT pa= ss end to end? >>>>=20 >>>> I'm not sure the following would fall into your category but in additi= on to prefixing thaty's already been mentioned, you may also have cases whe= re the conversion from the dialing plan to the numbering plan involves a "d= egree of complexity" that cannot be expected from some endpoints because it= is more complex than just "replace the national prefix, aka 'trunk prefix'= , with the relevant geographic country code" to get the full E.164 canonica= l form. (for example, supposing 0 as a national trunk code, some dialing pl= ans map 0-XXX to _several_ geographic country codes +CC-XXX depending on th= e value of XXX).=20 >>>>=20 >>>> One simple way to support these formats is to allow the endpoint (eg a= PBX) to always send +CC-XXX with one given CC (and therefore potentially i= ncorrect canonical form) and correct it with the right mapping downstream. = On may argue that it is a bit of a hack to make up for the lack of support = of a phone-context by the endpoints, but you generally have to make do with= out it.=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>>> Of Rosen, Brian >>>> Sent: Friday, June 07, 2013 7:20 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Can canonical phone numbers survive SBCs and other mid= dle boxes? >>>>=20 >>>> The fundamental idea that we have here is that you sign a set of infor= mation with a credential, and you pass the signature and a pointer to the c= redential in SIP signaling.=20 >>>>=20 >>>> We have some disagreements about what is signed. >>>>=20 >>>> Henning has proposed that we canonicalize the From and To phone number= s, we include a timestamp and some form of call-id, possibly the INSIPID id= . =20 >>>>=20 >>>> There are assertions that you can't use From/To, because middle boxes = change them. Some have suggested using P-A-I and other headers instead. >>>>=20 >>>> Hadriel wrote a draft about why From and To get modified: >>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>=20 >>>> After reading it, I am unclear if a canonicalized e.164 would make it = through. The reasons given seem to indicate they would. They change domai= ns, they change prefixes, but they don't seem to change the actual telephon= e number. >>>>=20 >>>> Can we come up with examples where a canonicalized e.164 would NOT pas= s end to end? >>>>=20 >>>> Brian >>>>=20 >>>> ____________________________________________________________________ >>>> _ ____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, France Telecom - Orange decline toute responsabilite si = ce message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged information that may be protected by law; they should not b= e 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, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>=20 >>>=20 >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, France Telecom - Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez le signaler a l'expediteur et le detruire ainsi que les pieces jointes.= Les messages electroniques etant susceptibles d'alteration, France Telecom= - 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, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=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 Mon Jun 10 09:57: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 69CCC21F96C6 for ; Mon, 10 Jun 2013 09:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 rbu0EgcWsSSG for ; Mon, 10 Jun 2013 09:57:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 595EB21F992B for ; Mon, 10 Jun 2013 09:57:02 -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 r5AGuwdQ017536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 16:56:59 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 r5AGv0Nx005869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 16:57:00 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 r5AGv0Wo005851; Mon, 10 Jun 2013 16:57:00 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 09:57:00 -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, 10 Jun 2013 12:56:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67DB3A45-D8EC-40B3-87D0-37C753D9529D@oracle.com> References: <29234_1370880859_51B5FB5B_29234_222_1_B5939C6860701C49AA39C5DA5189448B0A26B3@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:57:08 -0000 Sure. Either way. -hadriel On Jun 10, 2013, at 12:29 PM, "Rosen, Brian" = wrote: > The customer, if it has a cert, can issue a cert to the call center. = It doesn't have to share it's private key. >=20 > Brian >=20 > On Jun 10, 2013, at 12:23 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> On Jun 10, 2013, at 12:14 PM, wrote: >>=20 >>> However, for cases where for (arguably) good reasons relative to the = service (eg a call centre) that number may be any number provided by the = customer of that service, I don't see how it could. Im' not even = advocating it should, given the generality of the case, I'm just saying = such cases do exist, which is where this thread started from. =20 >>=20 >> If the certificate-for-a-number model is used, then in theory the = customer of the service provides the call center with its private key to = sign outbound calls of its number. (or more likely, its service provider = would need to do it) >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jun 10 09:59: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 0381421F8EF2 for ; Mon, 10 Jun 2013 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 6iCCtrY4YUhO for ; Mon, 10 Jun 2013 09:59:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9498421F9634 for ; Mon, 10 Jun 2013 09:59:23 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5AGxLE2020137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 16:59:23 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 r5AGxLxp011447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 16:59: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 r5AGxKbS011433; Mon, 10 Jun 2013 16:59:20 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 09:59:20 -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, 10 Jun 2013 12:59:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Torrey Searle X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 16:59:29 -0000 I was under the impression the User-to-user param didn't often survive = very far on SS7, not beyond the local carrier. True? -hadriel On Jun 9, 2013, at 7:05 AM, Torrey Searle wrote: > >I'm not sure I understand the logic here. > >Why would we trust a "not-evil" bit coming in from SS7/ISUP? > >Why wouldn't all pink carriers just start setting that bit? >=20 >=20 > In the case of > SIP->SS7->SIP =20 >=20 >=20 > Wouldn't it be interesting for the Calling SIP party to put a signed = hash >=20 > of the called/calling number into A sip header, copy that into the SS7 = User-To-User > Header and then put it back into a SIP header on the destination sip = leg? >=20 > That way the Destination SIP network only needs to trust the = originating sip >=20 > network and not any intermediate SS7 networks. >=20 >=20 > Regards, > Torrey > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jun 10 10:09: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 2084D21F85E6 for ; Mon, 10 Jun 2013 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 itB4im2V4Nl4 for ; Mon, 10 Jun 2013 10:09:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4C921F86AE for ; Mon, 10 Jun 2013 10:09:34 -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 r5AH9Uci032639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 17:09:31 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 r5AH9WRL003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 17:09:32 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 r5AH9W0x009669; Mon, 10 Jun 2013 17:09:32 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 10:09: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: <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> Date: Mon, 10 Jun 2013 13:09:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31B094AA-961A-4DFE-A9F6-B12209396E83@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "Dwight, Timothy M \(Tim\)" , "philippe.fouquart@orange.com" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 17:09:42 -0000 On Jun 10, 2013, at 12:53 PM, "Rosen, Brian" = wrote: > Some folks on the list have proposed to use P-Asserted-Identity = instead of From. Others want to be able to make the mechanism end to = end (instead of SP to SP) and would prefer to base the sig on =46rom = rather than P-A-I. > Brian P-A-I is not really just SP-to-SP. It is sometimes sent to the = PBX/callee as well, and there's no real reason for it not to be afaict, = unless the call is anonymous/private. It's just that most SPs don't let = their customers generate one as a caller (or rather, don't believe it if = they do). But yes, the draft proposing to sign the PAI is definitely intended for = SPs to do the signing/verifying. -hadriel From richard@shockey.us Mon Jun 10 10:45: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 6AF6721F992B for ; Mon, 10 Jun 2013 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.184, 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 UFjAfL6zFLIp for ; Mon, 10 Jun 2013 10:45:36 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 701E221F9926 for ; Mon, 10 Jun 2013 10:45:36 -0700 (PDT) Received: (qmail 20933 invoked by uid 0); 10 Jun 2013 17:38:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 10 Jun 2013 17:38:35 -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=rDBOXIx5VswOMkWYf7C7bH3NzYKYeCrytCBy/Ssh++Q=; b=eKV1qZ4f3tQ30djcmaSjYeQ0J1LxZjqNqVIaP6FQLXFXY7SjUc4AZM14YSpcdRAIryxsD0TRZZf+c8PUFCScsUrukklzHGuKD3CtO5//OyojwXpP6X0SgyOGKAjUow5d; Received: from [72.66.111.124] (port=54172 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Um639-0002iv-83; Mon, 10 Jun 2013 11:38:35 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , "'Olle E. Johansson'" References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> In-Reply-To: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> Date: Mon, 10 Jun 2013 13:38:30 -0400 Message-ID: <018701ce6601$53a6e4d0$faf4ae70$@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: AQH77DZ6wcB0JKbMsr3VXx1DtbtQRAHTQ8JPAXMx++GYufSOkA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: philippe.fouquart@orange.com, stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 17:45:41 -0000 Correct. In fact it would be useful to stop thinking about number blocks at all. LNP does create some issues but those can be dealt with as Brian points out. It should come as no surprise that some NRA's are looking at the entire structure of E.164 allocation with an eye to single number issuance in order to alleviate possible number exhaust issues, among other things. In the future it is not unreasonable to consider Phone Numbers as "domain names". -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, June 10, 2013 12:11 PM To: Olle E. Johansson Cc: philippe.fouquart@orange.com; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? A proposal on the table is that the PKI for Telephone Numbers (TNs) follows the TN delegation chain. The root of trust is the national regulator, or some contractor to it. When numbers are delegated, a cert for that delegation goes with it. Numbers can be subdelgated, certs with the sub delegation follow. So you are "authoritative" for a number if you have been delegated (or sub delegated) that number, and have the cert for it. Every country has a delegation system for numbers. There is a complication with number portability that might cause a specific number in a range to no longer be valid, but there are simple solutions to that, depending on how a country implements number portability. Brian On Jun 10, 2013, at 11:54 AM, Olle E. Johansson wrote: > > 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : > >> In order for that to work, the intermediary has to be authoritative >> for the number. >> Would that work? > Have we defined "authoritative" for a specific number? > > /O >> >> Brian >> >> >> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >> wrote: >> >>> I assume the initial signing to be done by the endpoint, the pbx, >>> which has authority over the full E.164 number. >>> >>> If the canonical form is incorrect (the international format is >>> incorrect or the number is only provided in national format), I >>> would have imagined that the intermediary would have to provide a >>> correct canonical form and >>> (?) resign. >>> >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 4:14 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: Rosen, Brian; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>> other middle boxes? >>> >>> I never thought about resigning. >>> >>> Whatever element signs has to be authoritative for the e.164. In >>> your example, who do you think would do the initial signing and who >>> would re-sign? >>> >>> Brian >>> >>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>> >>>> Thanks. Am I then right in rephrasing this as "it isn't going to be >>>> a problem if and only if the intermediary that corrects the >>>> canonical form is also able to [re]sign the [corrected] number?" >>>> >>>> For CgPNs, I guess this would work for a pbx using numbers under >>>> ranges of their service provider (or ported to it), but may not >>>> easily work for (more interesting) cases where the CgPN is >>>> completely unrelated with the call centre that initiated the call >>>> (eg a concierge service using their customer's individual number, the "Permitted spoofing" case). >>>> >>>> Regards, >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 3:28 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>>> other middle boxes? >>>> >>>> If both the endpoints and their SPs understand the rules, then they >>>> can generate the signature and check it. >>>> Might have problems with intermediaries that couldn't do that unless >>>> the To was rewritten at some point. It would seem to me that in order >>>> to route these calls, that's what would have to happen unless you >>>> are using P-A-I passed between carriers to carry the decoded e.164. >>>> >>>> Brian >>>> >>>> >>>> On Jun 10, 2013, at 9:06 AM, >>>> wrote: >>>> >>>>>> Can we come up with examples where a canonicalized e.164 would >>>>>> NOT pass end to end? >>>>> >>>>> I'm not sure the following would fall into your category but in >>>>> addition to prefixing thaty's already been mentioned, you may also >>>>> have cases where the conversion from the dialing plan to the >>>>> numbering plan involves a "degree of complexity" that cannot be >>>>> expected from some endpoints because it is more complex than just >>>>> "replace the national prefix, aka 'trunk prefix', with the relevant geographic country code" >>>>> to get the full E.164 canonical form. (for example, supposing 0 as >>>>> a national trunk code, some dialing plans map 0-XXX to _several_ >>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>> >>>>> One simple way to support these formats is to allow the endpoint >>>>> (eg a >>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>> potentially incorrect canonical form) and correct it with the >>>>> right mapping downstream. On may argue that it is a bit of a hack >>>>> to make up for the lack of support of a phone-context by the >>>>> endpoints, but you generally have to make do without it. >>>>> >>>>> Regards, >>>>> >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>> >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>> Behalf Of Rosen, Brian >>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>> To: stir@ietf.org >>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>>> middle boxes? >>>>> >>>>> The fundamental idea that we have here is that you sign a set of >>>>> information with a credential, and you pass the signature and a >>>>> pointer to the credential in SIP signaling. >>>>> >>>>> We have some disagreements about what is signed. >>>>> >>>>> Henning has proposed that we canonicalize the From and To phone >>>>> numbers, we include a timestamp and some form of call-id, possibly >>>>> the INSIPID id. >>>>> >>>>> There are assertions that you can't use From/To, because middle >>>>> boxes change them. Some have suggested using P-A-I and other headers instead. >>>>> >>>>> Hadriel wrote a draft about why From and To get modified: >>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>> >>>>> After reading it, I am unclear if a canonicalized e.164 would make >>>>> it through. The reasons given seem to indicate they would. They >>>>> change domains, they change prefixes, but they don't seem to >>>>> change the actual telephone number. >>>>> >>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>> pass end to end? >>>>> >>>>> Brian >>>>> >>>>> >>>>> __________________________________________________________________ >>>>> ______ _________________________________________________ >>>>> >>>>> 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, France Telecom - 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, France Telecom - Orange is not liable >>>>> for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>> >>>> >>>> >>>> >>>> ___________________________________________________________________ >>>> ______ ________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>> detruire ainsi que les pieces jointes. Les messages electroniques >>>> etant susceptibles d'alteration, France Telecom - 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, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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, France Telecom - 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, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>> >> >> _______________________________________________ >> 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 oej@edvina.net Mon Jun 10 11: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 0146121F9A1F for ; Mon, 10 Jun 2013 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 e00oPDr7eY8S for ; Mon, 10 Jun 2013 11:31:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC3A21F9A1E for ; Mon, 10 Jun 2013 11:31:43 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 16F1693C1AF; Mon, 10 Jun 2013 18:31:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> Date: Mon, 10 Jun 2013 20:31:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCD45C6-1FFF-4487-AE1B-F4708027268A@edvina.net> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1503) Cc: "stir@ietf.org" , "Olle E. Johansson" , "Dwight, Timothy M \(Tim\)" , "philippe.fouquart@orange.com" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 18:31:48 -0000 10 jun 2013 kl. 18:53 skrev "Rosen, Brian" : > The URI to the cert used for signing comes in the signaling. >=20 > Some folks on the list have proposed to use P-Asserted-Identity = instead of From. Others want to be able to make the mechanism end to = end (instead of SP to SP) and would prefer to base the sig on =46rom = rather than P-A-I. >=20 I think we have to separate phone numbers (E.164) from e-mail style SIP = uri's in this discussion. Just saying "The URI" is not enough. If I understand correctly this discussion is focused on the E.164 plan, = so either Tel: uri's or just a phone number that has some kind of relationship to the caller. In the case of e-mail = style SIP uri's the relationship is quite clear.=20 I think this is a reason why tel: was excluded from SIP identity - so = we're looking to close that hole and in this work exclude the sip:/sips: = URI's. /O > Brian >=20 > On Jun 10, 2013, at 12:42 PM, "Dwight, Timothy M \(Tim\)" = wrote: >=20 >> I guess that works as long as the number blocks are different, and = it's clear to the recipient whose public key he needs to use (the SP's = or that of the PBX). How would he know? Trial and error? >>=20 >> Also I don't know that it works in the "Vonage" scenario I referenced = obliquely below. >>=20 >> Tim >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >> Sent: Monday, June 10, 2013 10:47 AM >> To: Dwight, Timothy M (Tim) >> Cc: philippe.fouquart@orange.com; stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>=20 >> Well, the PBX would have a sub delegation from the SP with a narrower = scope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to = ..1999. It then may have delegated +CC-NPA-NXX-1300 to 1399 to the = PBX. The PBX could sign with its 1300-1399 cert and the SP could sign = with it's 1000-1999 cert. >>=20 >> Brian >>=20 >> On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" = >> wrote: >>=20 >>> I suppose it's possible that both the service provider to which the = number was assigned by the numbering plan authority, and the 'user' to = whom that service provider assigned it, may have access to the = associated private key. I am not comfortable with the security = implications of that, though. And (to Brian's subsequent question) I'm = not sure it works in all configurations, particularly I'm thinking of = one in which the entity to whom the number was assigned by the numbering = plan authority, not being the one providing PSTN ingress/egress services = to it. If you follow the goings-on in the US FCC you're no doubt = familiar with the recently-announced trial of that scenario. >>>=20 >>> I wonder if we're trying to solve the wrong problem. There is = already precedent for a 'user asserted' identity separate from a = 'network asserted' identity. Could we use the same / similar mechanisms = for both, but keep them separate? Or is there some underlying = assumption that were the FROM header sufficiently trustworthy, there = would be no further need for P-A-I? >>>=20 >>> I think keeping them separate, at least might simplify the issues = arising from too many entities needing access to the same private key. = As they say, 3 people can keep a secret only if 2 are dead. >>>=20 >>> Cheers, >>>=20 >>> tim >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >>> Of philippe.fouquart@orange.com >>> Sent: Monday, June 10, 2013 10:04 AM >>> To: Rosen, Brian >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>=20 >>> I assume the initial signing to be done by the endpoint, the pbx, = which has authority over the full E.164 number. >>>=20 >>> If the canonical form is incorrect (the international format is = incorrect or the number is only provided in national format), I would = have imagined that the intermediary would have to provide a correct = canonical form and (?) resign. =20 >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 4:14 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: Rosen, Brian; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>=20 >>> I never thought about resigning. >>>=20 >>> Whatever element signs has to be authoritative for the e.164. In = your example, who do you think would do the initial signing and who = would re-sign? >>>=20 >>> Brian >>>=20 >>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>=20 >>>> Thanks. Am I then right in rephrasing this as "it isn't going to be = a problem if and only if the intermediary that corrects the canonical = form is also able to [re]sign the [corrected] number?"=20 >>>>=20 >>>> For CgPNs, I guess this would work for a pbx using numbers under = ranges of their service provider (or ported to it), but may not easily = work for (more interesting) cases where the CgPN is completely unrelated = with the call centre that initiated the call (eg a concierge service = using their customer's individual number, the "Permitted spoofing" = case).=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 3:28 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>>=20 >>>> If both the endpoints and their SPs understand the rules, then they = can generate the signature and check it. >>>> Might have problems with intermediaries that couldn't do that = unless the To was rewritten at some point. It would seem to me that in = order to route these calls, that's what would have to happen unless you = are using P-A-I passed between carriers to carry the decoded e.164. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Jun 10, 2013, at 9:06 AM, >>>> wrote: >>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would = NOT pass end to end? >>>>>=20 >>>>> I'm not sure the following would fall into your category but in = addition to prefixing thaty's already been mentioned, you may also have = cases where the conversion from the dialing plan to the numbering plan = involves a "degree of complexity" that cannot be expected from some = endpoints because it is more complex than just "replace the national = prefix, aka 'trunk prefix', with the relevant geographic country code" = to get the full E.164 canonical form. (for example, supposing 0 as a = national trunk code, some dialing plans map 0-XXX to _several_ = geographic country codes +CC-XXX depending on the value of XXX).=20 >>>>>=20 >>>>> One simple way to support these formats is to allow the endpoint = (eg a PBX) to always send +CC-XXX with one given CC (and therefore = potentially incorrect canonical form) and correct it with the right = mapping downstream. On may argue that it is a bit of a hack to make up = for the lack of support of a phone-context by the endpoints, but you = generally have to make do without it.=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf=20 >>>>> Of Rosen, Brian >>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>> To: stir@ietf.org >>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other = middle boxes? >>>>>=20 >>>>> The fundamental idea that we have here is that you sign a set of = information with a credential, and you pass the signature and a pointer = to the credential in SIP signaling.=20 >>>>>=20 >>>>> We have some disagreements about what is signed. >>>>>=20 >>>>> Henning has proposed that we canonicalize the =46rom and To phone = numbers, we include a timestamp and some form of call-id, possibly the = INSIPID id. =20 >>>>>=20 >>>>> There are assertions that you can't use From/To, because middle = boxes change them. Some have suggested using P-A-I and other headers = instead. >>>>>=20 >>>>> Hadriel wrote a draft about why =46rom and To get modified: >>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>=20 >>>>> After reading it, I am unclear if a canonicalized e.164 would make = it through. The reasons given seem to indicate they would. They change = domains, they change prefixes, but they don't seem to change the actual = telephone number. >>>>>=20 >>>>> Can we come up with examples where a canonicalized e.164 would NOT = pass end to end? >>>>>=20 >>>>> Brian >>>>>=20 >>>>> = ____________________________________________________________________ >>>>> _ ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>>> 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, France Telecom - Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>=20 >>>>=20 >>>> = _____________________________________________________________________ >>>> _ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses,=20 >>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, France Telecom - Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=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, France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>> Thank you. >>>=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 From brian.rosen@neustar.biz Mon Jun 10 11:35: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 EBC6621F9A24 for ; Mon, 10 Jun 2013 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 7H+3l38niAql for ; Mon, 10 Jun 2013 11:35:39 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A397021F9A1F for ; Mon, 10 Jun 2013 11:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370889825; x=1686233302; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=QrplI5CxKH CPbfE4xxq4QZLdU9vXfN6kZDLi56z5HxA=; b=ITYUs6pjJyLwmwKHiRd12Pnb5E c3Xl0d2sGLrH8kdeJJo5u5GDEmexk4sZmuMJNTcOoYvGVBu7dHd7sGGQp7bg== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26045672; Mon, 10 Jun 2013 14:43:44 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 14:35:34 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 14:35:29 -0400 From: "Rosen, Brian" To: "Olle E. Johansson" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuAgAAJ9gCAAAINgP//v1IAgABTOYCAABtlAIAAARUA Date: Mon, 10 Jun 2013 18:35:29 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> <7BCD45C6-1FFF-4487-AE1B-F4708027268A@edvina.net> In-Reply-To: <7BCD45C6-1FFF-4487-AE1B-F4708027268A@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BMMglGihdswwY8EOCGBZ9g== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "philippe.fouquart@orange.com" , "Dwight, Timothy M \(Tim\)" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 18:35:43 -0000 Well, mostly, yes. =20 The work is specifically aimed at telephone numbers as identifiers. I thin= k we would like to see a way to expand beyond that some day, but the target= is telephone number based identifiers. How you encode the number (as a tel: uri or a sip uri with user=3Dphone) in= To/From/P-A-I/... may not matter if this discussion on canonicalization wo= rks out. Brian On Jun 10, 2013, at 2:31 PM, "Olle E. Johansson" wrote: >=20 > 10 jun 2013 kl. 18:53 skrev "Rosen, Brian" : >=20 >> The URI to the cert used for signing comes in the signaling. >>=20 >> Some folks on the list have proposed to use P-Asserted-Identity instead = of From. Others want to be able to make the mechanism end to end (instead = of SP to SP) and would prefer to base the sig on From rather than P-A-I. >>=20 > I think we have to separate phone numbers (E.164) from e-mail style SIP u= ri's in this discussion. Just saying "The URI" is not enough. >=20 > If I understand correctly this discussion is focused on the E.164 plan, s= o either Tel: uri's or just a phone number > that has some kind of relationship to the caller. In the case of e-mail s= tyle SIP uri's the relationship > is quite clear.=20 >=20 > I think this is a reason why tel: was excluded from SIP identity - so we'= re looking to close that hole and in this work exclude the sip:/sips: URI's= . >=20 > /O >=20 >> Brian >>=20 >> On Jun 10, 2013, at 12:42 PM, "Dwight, Timothy M \(Tim\)" wrote: >>=20 >>> I guess that works as long as the number blocks are different, and it's= clear to the recipient whose public key he needs to use (the SP's or that = of the PBX). How would he know? Trial and error? >>>=20 >>> Also I don't know that it works in the "Vonage" scenario I referenced o= bliquely below. >>>=20 >>> Tim >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >>> Sent: Monday, June 10, 2013 10:47 AM >>> To: Dwight, Timothy M (Tim) >>> Cc: philippe.fouquart@orange.com; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other = middle boxes? >>>=20 >>> Well, the PBX would have a sub delegation from the SP with a narrower s= cope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999.= It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX= could sign with its 1300-1399 cert and the SP could sign with it's 1000-19= 99 cert. >>>=20 >>> Brian >>>=20 >>> On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" >>> wrote: >>>=20 >>>> I suppose it's possible that both the service provider to which the nu= mber was assigned by the numbering plan authority, and the 'user' to whom t= hat service provider assigned it, may have access to the associated private= key. I am not comfortable with the security implications of that, though.= And (to Brian's subsequent question) I'm not sure it works in all configu= rations, particularly I'm thinking of one in which the entity to whom the n= umber was assigned by the numbering plan authority, not being the one provi= ding PSTN ingress/egress services to it. If you follow the goings-on in th= e US FCC you're no doubt familiar with the recently-announced trial of that= scenario. >>>>=20 >>>> I wonder if we're trying to solve the wrong problem. There is already= precedent for a 'user asserted' identity separate from a 'network asserted= ' identity. Could we use the same / similar mechanisms for both, but keep = them separate? Or is there some underlying assumption that were the FROM h= eader sufficiently trustworthy, there would be no further need for P-A-I? >>>>=20 >>>> I think keeping them separate, at least might simplify the issues aris= ing from too many entities needing access to the same private key. As they= say, 3 people can keep a secret only if 2 are dead. >>>>=20 >>>> Cheers, >>>>=20 >>>> tim >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >>>> Of philippe.fouquart@orange.com >>>> Sent: Monday, June 10, 2013 10:04 AM >>>> To: Rosen, Brian >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other= middle boxes? >>>>=20 >>>> I assume the initial signing to be done by the endpoint, the pbx, whic= h has authority over the full E.164 number. >>>>=20 >>>> If the canonical form is incorrect (the international format is incorr= ect or the number is only provided in national format), I would have imagin= ed that the intermediary would have to provide a correct canonical form and= (?) resign. =20 >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 4:14 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other= middle boxes? >>>>=20 >>>> I never thought about resigning. >>>>=20 >>>> Whatever element signs has to be authoritative for the e.164. In your= example, who do you think would do the initial signing and who would re-si= gn? >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>>=20 >>>>> Thanks. Am I then right in rephrasing this as "it isn't going to be a= problem if and only if the intermediary that corrects the canonical form i= s also able to [re]sign the [corrected] number?"=20 >>>>>=20 >>>>> For CgPNs, I guess this would work for a pbx using numbers under rang= es of their service provider (or ported to it), but may not easily work for= (more interesting) cases where the CgPN is completely unrelated with the c= all centre that initiated the call (eg a concierge service using their cust= omer's individual number, the "Permitted spoofing" case).=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and othe= r middle boxes? >>>>>=20 >>>>> If both the endpoints and their SPs understand the rules, then they c= an generate the signature and check it. >>>>> Might have problems with intermediaries that couldn't do that unless = the To was rewritten at some point. It would seem to me that in order to = route these calls, that's what would have to happen unless you are using P-= A-I passed between carriers to carry the decoded e.164. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Jun 10, 2013, at 9:06 AM, >>>>> wrote: >>>>>=20 >>>>>>> Can we come up with examples where a canonicalized e.164 would NOT = pass end to end? >>>>>>=20 >>>>>> I'm not sure the following would fall into your category but in addi= tion to prefixing thaty's already been mentioned, you may also have cases w= here the conversion from the dialing plan to the numbering plan involves a = "degree of complexity" that cannot be expected from some endpoints because = it is more complex than just "replace the national prefix, aka 'trunk prefi= x', with the relevant geographic country code" to get the full E.164 canoni= cal form. (for example, supposing 0 as a national trunk code, some dialing = plans map 0-XXX to _several_ geographic country codes +CC-XXX depending on = the value of XXX).=20 >>>>>>=20 >>>>>> One simple way to support these formats is to allow the endpoint (eg= a PBX) to always send +CC-XXX with one given CC (and therefore potentially= incorrect canonical form) and correct it with the right mapping downstream= . On may argue that it is a bit of a hack to make up for the lack of suppor= t of a phone-context by the endpoints, but you generally have to make do wi= thout it.=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf= =20 >>>>>> Of Rosen, Brian >>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>>>>>=20 >>>>>> The fundamental idea that we have here is that you sign a set of inf= ormation with a credential, and you pass the signature and a pointer to the= credential in SIP signaling.=20 >>>>>>=20 >>>>>> We have some disagreements about what is signed. >>>>>>=20 >>>>>> Henning has proposed that we canonicalize the From and To phone numb= ers, we include a timestamp and some form of call-id, possibly the INSIPID = id. =20 >>>>>>=20 >>>>>> There are assertions that you can't use From/To, because middle boxe= s change them. Some have suggested using P-A-I and other headers instead. >>>>>>=20 >>>>>> Hadriel wrote a draft about why From and To get modified: >>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>>=20 >>>>>> After reading it, I am unclear if a canonicalized e.164 would make i= t through. The reasons given seem to indicate they would. They change dom= ains, they change prefixes, but they don't seem to change the actual teleph= one number. >>>>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would NOT p= ass end to end? >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> ____________________________________________________________________ >>>>>> _ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, France Telecom - Orange decline toute responsabilite s= i ce message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _____________________________________________________________________ >>>>> _ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,= =20 >>>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles d'alt= eration, France Telecom - Orange decline toute responsabilite si ce message= a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> 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 an= d delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for m= essages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=20 >>>> ______________________________________________________________________ >>>> ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite= s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe= s. Les messages electroniques etant susceptibles d'alteration, France Telec= om - Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d 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, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >>>> Thank you. >>>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From oej@edvina.net Mon Jun 10 11:45: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 BAD5121F8EEA for ; Mon, 10 Jun 2013 11:45:42 -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 Kd-gXwhmYQAu for ; Mon, 10 Jun 2013 11:45:41 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFBF21F94E1 for ; Mon, 10 Jun 2013 11:45:39 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4943493C2A2; Mon, 10 Jun 2013 18:45:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> Date: Mon, 10 Jun 2013 20:45:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> To: "Richard Shockey" X-Mailer: Apple Mail (2.1503) Cc: "'Rosen, Brian'" , "Olle E. Johansson" , stir@ietf.org, philippe.fouquart@orange.com Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 18:45:42 -0000 10 jun 2013 kl. 19:38 skrev "Richard Shockey" : >=20 > Correct. In fact it would be useful to stop thinking about number = blocks at > all. LNP does create some issues but those can be dealt with as Brian > points out. It should come as no surprise that some NRA's are looking = at > the entire structure of E.164 allocation with an eye to single number > issuance in order to alleviate possible number exhaust issues, among = other > things. In the future it is not unreasonable to consider Phone = Numbers as > "domain names". =20 If I'm correct a delegation in Germany more or less works that way. If I get +468964020 in Sweden, that's one single number. In Germany, it would be a prefix that can be extended arbitrary. We have to be careful with PKIs. If we're going down that path, the=20 verification process will be painful. Switchover during the porting = process will have to be instant - if we don't allow two certs for the same = number. How many verifications can happen during one call from Alice to Bob? /O >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Rosen, Brian > Sent: Monday, June 10, 2013 12:11 PM > To: Olle E. Johansson > Cc: philippe.fouquart@orange.com; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? >=20 > A proposal on the table is that the PKI for Telephone Numbers (TNs) = follows > the TN delegation chain. The root of trust is the national regulator, = or > some contractor to it. When numbers are delegated, a cert for that > delegation goes with it. Numbers can be subdelgated, certs with the = sub > delegation follow. So you are "authoritative" for a number if you = have been > delegated (or sub delegated) that number, and have the cert for it. = Every > country has a delegation system for numbers. >=20 > There is a complication with number portability that might cause a = specific > number in a range to no longer be valid, but there are simple = solutions to > that, depending on how a country implements number portability. >=20 > Brian >=20 > On Jun 10, 2013, at 11:54 AM, Olle E. Johansson = wrote: >=20 >>=20 >> 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >>=20 >>> In order for that to work, the intermediary has to be authoritative=20= >>> for the number. >>> Would that work? >> Have we defined "authoritative" for a specific number? >>=20 >> /O >>>=20 >>> Brian >>>=20 >>>=20 >>> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >>> wrote: >>>=20 >>>> I assume the initial signing to be done by the endpoint, the pbx,=20= >>>> which has authority over the full E.164 number. >>>>=20 >>>> If the canonical form is incorrect (the international format is=20 >>>> incorrect or the number is only provided in national format), I=20 >>>> would have imagined that the intermediary would have to provide a=20= >>>> correct canonical form and >>>> (?) resign. =20 >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 4:14 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and=20 >>>> other middle boxes? >>>>=20 >>>> I never thought about resigning. >>>>=20 >>>> Whatever element signs has to be authoritative for the e.164. In=20= >>>> your example, who do you think would do the initial signing and who=20= >>>> would re-sign? >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>>=20 >>>>> Thanks. Am I then right in rephrasing this as "it isn't going to = be=20 >>>>> a problem if and only if the intermediary that corrects the=20 >>>>> canonical form is also able to [re]sign the [corrected] number?" >>>>>=20 >>>>> For CgPNs, I guess this would work for a pbx using numbers under=20= >>>>> ranges of their service provider (or ported to it), but may not=20 >>>>> easily work for (more interesting) cases where the CgPN is=20 >>>>> completely unrelated with the call centre that initiated the call=20= >>>>> (eg a concierge service using their customer's individual number, = the > "Permitted spoofing" case). >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and=20= >>>>> other middle boxes? >>>>>=20 >>>>> If both the endpoints and their SPs understand the rules, then = they=20 >>>>> can generate the signature and check it. >>>>> Might have problems with intermediaries that couldn't do that = unless >>>>> the To was rewritten at some point. It would seem to me that in = order >>>>> to route these calls, that's what would have to happen unless you=20= >>>>> are using P-A-I passed between carriers to carry the decoded = e.164. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Jun 10, 2013, at 9:06 AM, >>>>> wrote: >>>>>=20 >>>>>>> Can we come up with examples where a canonicalized e.164 would=20= >>>>>>> NOT pass end to end? >>>>>>=20 >>>>>> I'm not sure the following would fall into your category but in=20= >>>>>> addition to prefixing thaty's already been mentioned, you may = also=20 >>>>>> have cases where the conversion from the dialing plan to the=20 >>>>>> numbering plan involves a "degree of complexity" that cannot be=20= >>>>>> expected from some endpoints because it is more complex than just=20= >>>>>> "replace the national prefix, aka 'trunk prefix', with the = relevant > geographic country code" >>>>>> to get the full E.164 canonical form. (for example, supposing 0 = as=20 >>>>>> a national trunk code, some dialing plans map 0-XXX to _several_=20= >>>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>>=20 >>>>>> One simple way to support these formats is to allow the endpoint=20= >>>>>> (eg a >>>>>> PBX) to always send +CC-XXX with one given CC (and therefore=20 >>>>>> potentially incorrect canonical form) and correct it with the=20 >>>>>> right mapping downstream. On may argue that it is a bit of a hack=20= >>>>>> to make up for the lack of support of a phone-context by the=20 >>>>>> endpoints, but you generally have to make do without it. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>> Behalf Of Rosen, Brian >>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and = other=20 >>>>>> middle boxes? >>>>>>=20 >>>>>> The fundamental idea that we have here is that you sign a set of=20= >>>>>> information with a credential, and you pass the signature and a=20= >>>>>> pointer to the credential in SIP signaling. >>>>>>=20 >>>>>> We have some disagreements about what is signed. >>>>>>=20 >>>>>> Henning has proposed that we canonicalize the =46rom and To phone=20= >>>>>> numbers, we include a timestamp and some form of call-id, = possibly=20 >>>>>> the INSIPID id. >>>>>>=20 >>>>>> There are assertions that you can't use From/To, because middle=20= >>>>>> boxes change them. Some have suggested using P-A-I and other = headers > instead. >>>>>>=20 >>>>>> Hadriel wrote a draft about why =46rom and To get modified: >>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>>=20 >>>>>> After reading it, I am unclear if a canonicalized e.164 would = make=20 >>>>>> it through. The reasons given seem to indicate they would. They=20= >>>>>> change domains, they change prefixes, but they don't seem to=20 >>>>>> change the actual telephone number. >>>>>>=20 >>>>>> Can we come up with examples where a canonicalized e.164 would = NOT=20 >>>>>> pass end to end? >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> = __________________________________________________________________ >>>>>> ______ _________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations=20 >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu=20 >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20= >>>>>> detruire ainsi que les pieces jointes. Les messages electroniques=20= >>>>>> etant susceptibles d'alteration, France Telecom - Orange decline=20= >>>>>> toute responsabilite si ce message a ete altere, deforme ou=20 >>>>>> falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> privileged information that may be protected by law; they should=20= >>>>>> not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender=20 >>>>>> and delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable=20= >>>>>> for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ___________________________________________________________________ >>>>> ______ ________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20= >>>>> detruire ainsi que les pieces jointes. Les messages electroniques=20= >>>>> etant susceptibles d'alteration, France Telecom - Orange decline=20= >>>>> toute responsabilite si ce message a ete altere, deforme ou=20 >>>>> falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> privileged information that may be protected by law; they should=20= >>>>> not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender=20= >>>>> and delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable = for=20 >>>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=20 >>>> = ____________________________________________________________________ >>>> ______ _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20= >>>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>>> detruire ainsi que les pieces jointes. Les messages electroniques=20= >>>> etant susceptibles d'alteration, France Telecom - Orange decline=20 >>>> toute responsabilite si ce message a ete altere, deforme ou=20 >>>> falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or=20 >>>> privileged information that may be protected by law; they should = not=20 >>>> be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender=20= >>>> and delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for=20= >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Mon Jun 10 11:58: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 EA60D21F8546 for ; Mon, 10 Jun 2013 11:58:40 -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 I0anBUXgXEFd for ; Mon, 10 Jun 2013 11:58:37 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4663721F85B4 for ; Mon, 10 Jun 2013 11:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370890641; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=exGxHofP+0 rxXiak9wB6Fwc4kE0fd5tdcKAsfzsYCsE=; b=SxPOkGgPCVMzYzz+UEnSLEjfJQ fy6AClt6sPxNzbdjXCiiqcTsNYvbEKpzaWqoDyX9PxRuNdtaffOdVdxdZTvQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20795451; Mon, 10 Jun 2013 14:57:19 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 14:58:13 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 14:58:11 -0400 From: "Rosen, Brian" To: "Olle E. Johansson" , Richard Shockey Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABKAAgAAYjACAABLAAP//wHIA Date: Mon, 10 Jun 2013 18:58:10 +0000 Message-ID: In-Reply-To: <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4tURG11CULWSgAjHYg+fBA== Content-Type: text/plain; charset="us-ascii" Content-ID: <7F5BC055F8E6EA40A5264087A2F448F9@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 18:58:41 -0000 Yeah, the basic variable length number is fairly easy to handle, but only if you have the full number (no missing digits, other than perhaps the country code). If you have the full e.164, no problem. All the existing number portability schemes have some kind of changeover time measured in minutes, hours or days depending on the country. The cut-over doesn't have to be instantaneous. Where there is a database, the database could provide a validation ("is this specific TN still valid for the range this cert covers?"). For countries that use forwarding schemes, the original number holder would issue a cert to the gaining SP. To stop the problem, I think we need to at least start with verification across SP boundaries and the termination. We want to get to the point where an SP doesn't accept calls from a downstream SP that isn't verifiable. Long term, that might be more of an audit between SPs, rather than a 100% check, and I think we would see 100% verification at the end of the call (ideally the end device, but perhaps the termination SP). Brian On 6/10/13 2:45 PM, "Olle E. Johansson" wrote: > >10 jun 2013 kl. 19:38 skrev "Richard Shockey" : > >>=20 >> Correct. In fact it would be useful to stop thinking about number >>blocks at >> all. LNP does create some issues but those can be dealt with as Brian >> points out. It should come as no surprise that some NRA's are looking >>at >> the entire structure of E.164 allocation with an eye to single number >> issuance in order to alleviate possible number exhaust issues, among >>other >> things. In the future it is not unreasonable to consider Phone >>Numbers as >> "domain names".=20 >If I'm correct a delegation in Germany more or less works that way. >If I get +468964020 in Sweden, that's one single number. In Germany, >it would be a prefix that can be extended arbitrary. > >We have to be careful with PKIs. If we're going down that path, the >verification process will be painful. Switchover during the porting >process >will have to be instant - if we don't allow two certs for the same number. > >How many verifications can happen during one call from Alice to Bob? > >/O > >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Rosen, Brian >> Sent: Monday, June 10, 2013 12:11 PM >> To: Olle E. Johansson >> Cc: philippe.fouquart@orange.com; stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >> middle boxes? >>=20 >> A proposal on the table is that the PKI for Telephone Numbers (TNs) >>follows >> the TN delegation chain. The root of trust is the national regulator, >>or >> some contractor to it. When numbers are delegated, a cert for that >> delegation goes with it. Numbers can be subdelgated, certs with the sub >> delegation follow. So you are "authoritative" for a number if you have >>been >> delegated (or sub delegated) that number, and have the cert for it. >>Every >> country has a delegation system for numbers. >>=20 >> There is a complication with number portability that might cause a >>specific >> number in a range to no longer be valid, but there are simple solutions >>to >> that, depending on how a country implements number portability. >>=20 >> Brian >>=20 >> On Jun 10, 2013, at 11:54 AM, Olle E. Johansson wrote: >>=20 >>>=20 >>> 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >>>=20 >>>> In order for that to work, the intermediary has to be authoritative >>>> for the number. >>>> Would that work? >>> Have we defined "authoritative" for a specific number? >>>=20 >>> /O >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >>>> wrote: >>>>=20 >>>>> I assume the initial signing to be done by the endpoint, the pbx, >>>>> which has authority over the full E.164 number. >>>>>=20 >>>>> If the canonical form is incorrect (the international format is >>>>> incorrect or the number is only provided in national format), I >>>>> would have imagined that the intermediary would have to provide a >>>>> correct canonical form and >>>>> (?) resign. =20 >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Monday, June 10, 2013 4:14 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: Rosen, Brian; stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>>>> other middle boxes? >>>>>=20 >>>>> I never thought about resigning. >>>>>=20 >>>>> Whatever element signs has to be authoritative for the e.164. In >>>>> your example, who do you think would do the initial signing and who >>>>> would re-sign? >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>>>=20 >>>>>> Thanks. Am I then right in rephrasing this as "it isn't going to be >>>>>> a problem if and only if the intermediary that corrects the >>>>>> canonical form is also able to [re]sign the [corrected] number?" >>>>>>=20 >>>>>> For CgPNs, I guess this would work for a pbx using numbers under >>>>>> ranges of their service provider (or ported to it), but may not >>>>>> easily work for (more interesting) cases where the CgPN is >>>>>> completely unrelated with the call centre that initiated the call >>>>>> (eg a concierge service using their customer's individual number, >>>>>>the >> "Permitted spoofing" case). >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>>>>> other middle boxes? >>>>>>=20 >>>>>> If both the endpoints and their SPs understand the rules, then they >>>>>> can generate the signature and check it. >>>>>> Might have problems with intermediaries that couldn't do that unless >>>>>> the To was rewritten at some point. It would seem to me that in >>>>>>order >>>>>> to route these calls, that's what would have to happen unless you >>>>>> are using P-A-I passed between carriers to carry the decoded e.164. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> On Jun 10, 2013, at 9:06 AM, >>>>>> wrote: >>>>>>=20 >>>>>>>> Can we come up with examples where a canonicalized e.164 would >>>>>>>> NOT pass end to end? >>>>>>>=20 >>>>>>> I'm not sure the following would fall into your category but in >>>>>>> addition to prefixing thaty's already been mentioned, you may also >>>>>>> have cases where the conversion from the dialing plan to the >>>>>>> numbering plan involves a "degree of complexity" that cannot be >>>>>>> expected from some endpoints because it is more complex than just >>>>>>> "replace the national prefix, aka 'trunk prefix', with the relevant >> geographic country code" >>>>>>> to get the full E.164 canonical form. (for example, supposing 0 as >>>>>>> a national trunk code, some dialing plans map 0-XXX to _several_ >>>>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>>>=20 >>>>>>> One simple way to support these formats is to allow the endpoint >>>>>>> (eg a >>>>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>>>> potentially incorrect canonical form) and correct it with the >>>>>>> right mapping downstream. On may argue that it is a bit of a hack >>>>>>> to make up for the lack of support of a phone-context by the >>>>>>> endpoints, but you generally have to make do without it. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>=20 >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>> Behalf Of Rosen, Brian >>>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>>> To: stir@ietf.org >>>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>>>>> middle boxes? >>>>>>>=20 >>>>>>> The fundamental idea that we have here is that you sign a set of >>>>>>> information with a credential, and you pass the signature and a >>>>>>> pointer to the credential in SIP signaling. >>>>>>>=20 >>>>>>> We have some disagreements about what is signed. >>>>>>>=20 >>>>>>> Henning has proposed that we canonicalize the From and To phone >>>>>>> numbers, we include a timestamp and some form of call-id, possibly >>>>>>> the INSIPID id. >>>>>>>=20 >>>>>>> There are assertions that you can't use From/To, because middle >>>>>>> boxes change them. Some have suggested using P-A-I and other >>>>>>>headers >> instead. >>>>>>>=20 >>>>>>> Hadriel wrote a draft about why From and To get modified: >>>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>>>=20 >>>>>>> After reading it, I am unclear if a canonicalized e.164 would make >>>>>>> it through. The reasons given seem to indicate they would. They >>>>>>> change domains, they change prefixes, but they don't seem to >>>>>>> change the actual telephone number. >>>>>>>=20 >>>>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>>>> pass end to end? >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=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, France Telecom - 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, France Telecom - Orange is not liable >>>>>>> for messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=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, France Telecom - 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, France Telecom - Orange is not liable for >>>>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>>=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, France Telecom - 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, France Telecom - Orange is not liable for >>>>> messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=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 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From hgs@cs.columbia.edu Mon Jun 10 12:59: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 106FC21F9950 for ; Mon, 10 Jun 2013 12:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Y65H12b8vaqq for ; Mon, 10 Jun 2013 12:59:14 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1FD21F866E for ; Mon, 10 Jun 2013 12:59:14 -0700 (PDT) Received: from [172.20.21.119] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5AJx3sN019016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Jun 2013 15:59:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> Date: Mon, 10 Jun 2013 15:59:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "'Rosen, Brian'" , philippe.fouquart@orange.com, stir@ietf.org, Richard Shockey Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 19:59:21 -0000 For reasons related to legitimate spoofing, you probably want multiple = certs for the same number anyway. On Jun 10, 2013, at 2:45 PM, Olle E. Johansson wrote: >=20 > 10 jun 2013 kl. 19:38 skrev "Richard Shockey" : >=20 >>=20 >> Correct. In fact it would be useful to stop thinking about number = blocks at >> all. LNP does create some issues but those can be dealt with as = Brian >> points out. It should come as no surprise that some NRA's are = looking at >> the entire structure of E.164 allocation with an eye to single number >> issuance in order to alleviate possible number exhaust issues, among = other >> things. In the future it is not unreasonable to consider Phone = Numbers as >> "domain names". =20 > If I'm correct a delegation in Germany more or less works that way. > If I get +468964020 in Sweden, that's one single number. In Germany, > it would be a prefix that can be extended arbitrary. >=20 > We have to be careful with PKIs. If we're going down that path, the=20 > verification process will be painful. Switchover during the porting = process > will have to be instant - if we don't allow two certs for the same = number. >=20 > How many verifications can happen during one call from Alice to Bob? >=20 > /O From stephen.farrell@cs.tcd.ie Mon Jun 10 13:22: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 7205E21F9A19 for ; Mon, 10 Jun 2013 13:22:20 -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 IYUou5LGkrgj for ; Mon, 10 Jun 2013 13:22:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD621F9A18 for ; Mon, 10 Jun 2013 13:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38CD1BE7C; Mon, 10 Jun 2013 21:21:50 +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 OfOnyKwK8aqi; Mon, 10 Jun 2013 21:21:49 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.23.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1FD5BBE7B; Mon, 10 Jun 2013 21:21:49 +0100 (IST) Message-ID: <51B63552.3020607@cs.tcd.ie> Date: Mon, 10 Jun 2013 21:21:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> In-Reply-To: <51B231CE.7010908@dcrocker.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , Dave Crocker , "stir@ietf.org" Subject: [stir] DKIM-like key mgmt approach (was: Re: Can canonical phone numbers survive SBCs and other middle boxes?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:22:22 -0000 Hi On 06/07/2013 08:17 PM, Dave Crocker wrote: > (Just to be clear, I'm suggesting consideration of an approach; I'm not > sure it's the best one and I'm therefore not pushing for its adoption, > merely that it be explored.) > > Anyone can sign. They sign with a domain they own. So the signature > goes with the operator, not with the content (number, message, whatever.) I'd also like to understand the argument here as to whether a DKIM like approach to public key retrieval is good enough or not for this application. (Note that this is orthogonal to any discussion about a DKIM-like or 4474-like signature format, I'm just asking about public key retrieval now.) As with everything, I don't need to understand it now, but I do think that a bunch of folks here are making assumptions about PKI that might turn out to be a large amount of work later, e.g. that TN delegation specific certificate chains exist, can be found and can be verified efficiently. One could easily argue that since ENUM exists and DKIM key records exist (*) a DNS lookup could be the way to get signers' public keys without requiring any 5280 processing at all at the signer or verifier. One could further argue that that'd be sufficiently "secure" even without DNSSEC, in that it'd be enough to mitigate your robocaller issues on the basis that those robocallers aren't gonna MITM or poison DNS at the verifier. A similar argument was made for DKIM: since a bad DKIM signature is the same as no signature on a mail message, there's no need to require DNSSEC to get DKIM started. While its not quite the same in this context, it may be that one could argue that a reasonable threat model would not require the signature verifier (someone/thing en-route to the callee) to strongly verify the signing public key. (Ok, I can't resist adding a feature:-) If the DKIM key selector were modified (to put it in the key value) then you might also get some level of traceability in that one could trawl the DNS for signer's public keys. I don't know if that'd be good or bad. Anyway, for now, can we make sure this gets discussed before we plump for any specific key management solution? That could be now, or at a DISPATCH session or BoF or after a WG is chartered, I don't mind, so long as it is properly considered. S. (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. For the present discussion, just assume that the keys are in the "correct" kind of RR. From dhc2@dcrocker.net Mon Jun 10 13:41: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 B1C3921F9AA3 for ; Mon, 10 Jun 2013 13:41:44 -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 r+b5WQx7ovU9 for ; Mon, 10 Jun 2013 13:41:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6E21F96DF for ; Mon, 10 Jun 2013 13:41:39 -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 r5AKfVTo028025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 13:41:35 -0700 Message-ID: <51B639F8.9020600@dcrocker.net> Date: Mon, 10 Jun 2013 15:41:28 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> In-Reply-To: <51B63552.3020607@cs.tcd.ie> 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, 10 Jun 2013 13:41:35 -0700 (PDT) Cc: "Rosen, Brian" , "stir@ietf.org" Subject: [stir] selector naming (was - Re: DKIM-like key mgmt approach) 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, 10 Jun 2013 20:41:44 -0000 On 6/10/2013 3:21 PM, Stephen Farrell wrote: > (Ok, I can't resist adding a feature:-) If the DKIM key selector > were modified (to put it in the key value) then you might also get > some level of traceability in that one could trawl the DNS for > signer's public keys. I don't know if that'd be good or bad. This is a very specialized topic, given the overall posting, but I thought it worth noting for the archive that while I had missed the threat vector that predictable selectors pose, operators have not. At an anti-abuse meeting last week, they were discussing selector naming schemes (in support of rotating keys under different selectors) that are less predictable, to make trolling more effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Mon Jun 10 13:47: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 0741721F9A3A for ; Mon, 10 Jun 2013 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 xNDF0R3pcsi1 for ; Mon, 10 Jun 2013 13:47:26 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9910421F9A3B for ; Mon, 10 Jun 2013 13:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370897412; x=1686250944; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=XgwRhpcdMq ydHWnxA7LnoDgLKuhKYLRFTwyrY3u/VQw=; b=bejjEHbvGVJdzpp1tkcDFwNpVr a5Af6cmA9xuP5P6TC9ceQJ+jAafmKyoaxIW6+UJXVvoBWJaUos401LLxvWeQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24902902; Mon, 10 Jun 2013 16:50:11 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 16:47:09 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 16:47:06 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: DKIM-like key mgmt approach (was: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?) Thread-Index: AQHOZhgqW2uknb8aXUio4cBnVUD/gJkvrjKA Date: Mon, 10 Jun 2013 20:47:05 +0000 Message-ID: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> In-Reply-To: <51B63552.3020607@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: PD3kes3MDWeYAejWlewMQA== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker , "" Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical phone numbers survive SBCs and other middle boxes?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:47:31 -0000 ENUM does not exist. We have an RFC, but we have essentially no deployment. ENUM, as originally envisioned, was a public database. That is a complete = non-starter. ENUM tried to evolve to a private database, but in most places, it was not = possible to organize the relationships to make it work. What works is number delegation, and centralized databases like the US NPAC= . The proposed basic mechanism doesn't depend on a database of certs. The UR= L to the cert accompanies the signature. One of the proposed mechanisms for handling the so-called "out of band" mec= hanism that gets around SS7 links and SPs that don't preserve the signed in= formation does depend on such a database. I think that is a weakness. The= re are ways to create such a database which do not depend on DNS. Brian On Jun 10, 2013, at 4:21 PM, Stephen Farrell wr= ote: >=20 > Hi >=20 > On 06/07/2013 08:17 PM, Dave Crocker wrote: >> (Just to be clear, I'm suggesting consideration of an approach; I'm not >> sure it's the best one and I'm therefore not pushing for its adoption, >> merely that it be explored.) >>=20 >> Anyone can sign. They sign with a domain they own. So the signature >> goes with the operator, not with the content (number, message, whatever.= ) >=20 > I'd also like to understand the argument here as to whether a DKIM > like approach to public key retrieval is good enough or not for this > application. (Note that this is orthogonal to any discussion about a > DKIM-like or 4474-like signature format, I'm just asking about public > key retrieval now.) >=20 > As with everything, I don't need to understand it now, but I do think > that a bunch of folks here are making assumptions about PKI that might > turn out to be a large amount of work later, e.g. that TN delegation > specific certificate chains exist, can be found and can be verified > efficiently. >=20 > One could easily argue that since ENUM exists and DKIM key records > exist (*) a DNS lookup could be the way to get signers' public keys > without requiring any 5280 processing at all at the signer or verifier. >=20 > One could further argue that that'd be sufficiently "secure" even > without DNSSEC, in that it'd be enough to mitigate your robocaller > issues on the basis that those robocallers aren't gonna MITM or > poison DNS at the verifier. >=20 > A similar argument was made for DKIM: since a bad DKIM signature is > the same as no signature on a mail message, there's no need to require > DNSSEC to get DKIM started. >=20 > While its not quite the same in this context, it may be that one > could argue that a reasonable threat model would not require the > signature verifier (someone/thing en-route to the callee) to > strongly verify the signing public key. >=20 > (Ok, I can't resist adding a feature:-) If the DKIM key selector > were modified (to put it in the key value) then you might also get > some level of traceability in that one could trawl the DNS for > signer's public keys. I don't know if that'd be good or bad. >=20 > Anyway, for now, can we make sure this gets discussed before we > plump for any specific key management solution? That could be now, > or at a DISPATCH session or BoF or after a WG is chartered, I > don't mind, so long as it is properly considered. >=20 > S. >=20 > (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. > For the present discussion, just assume that the keys are in the > "correct" kind of RR. >=20 From pkyzivat@alum.mit.edu Mon Jun 10 13:49: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 AF50321E8094 for ; Mon, 10 Jun 2013 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.026, 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 LIRhbDZkds+2 for ; Mon, 10 Jun 2013 13:49:25 -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 B32B721E8085 for ; Mon, 10 Jun 2013 13:49:24 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id mjCP1l0070cZkys56kpQBE; Mon, 10 Jun 2013 20:49:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id mkpP1l00j3ZTu2S3WkpPFG; Mon, 10 Jun 2013 20:49:24 +0000 Message-ID: <51B63BD2.9010100@alum.mit.edu> Date: Mon, 10 Jun 2013 16:49:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <29959_1370869598_51B5CF5E_29959_900_1_B5939C6860701C49AA39C5DA5189448B0A2584@PEXCVZYM12.corporate.adroot.infra.ftgroup> <3834E56B-67D1-4F9C-95E8-52793BA87590@neustar.biz> <29959_1370873358_51B5DE0E_29959_5248_5_B5939C6860701C49AA39C5DA5189448B0A25EC@PEXCVZYM12.corporate.adroot.infra.ftgroup> <648A2752-9C61-41FB-A1BC-F856F07A739C@neustar.biz> <4218_1370876653_51B5EAEC_4218_2523_1_B5939C6860701C49AA39C5DA5189448B0A2635@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA301257492CD@FHDP1LUMXC7V31.us.one.verizon.com> <6B79E042-8AC5-4FFA-8204-C5DD2CE1D817@neustar.biz> <2B0F677F0B95454297753F58D4A07FA3012574939A@FHDP1LUMXC7V31.us.one.verizon.com> <24880EC6-6003-4A0B-9082-B56368967078@neustar.biz> <7BCD45C6-1FFF-4487-AE1B-F4708027268A@edvina.net> In-Reply-To: <7BCD45C6-1FFF-4487-AE1B-F4708027268A@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370897364; bh=qY6M1ZgTytWqhGtskl1Q2XkSYmMLOpPq8TduUZlpiMw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eiozx7qWj6xKyQEPJh+GOBmjNlL1Ar01er4MNmqmvzyoVxTfJuT1B3KK0dggmxWjX 9ewpVLFigiPW4aST21wbxYCtpDbh1+5cG0A9RWdEKEI35b1hcKiK1XW1rQMUjCwfwk Hc2CI/fxpgd7+Dl95kqrq3IH02790Y+cgrggGPsp77uBxSSGJ/6rn2UvrLSyOMNMPS LA3Lr1F33HQejMUz6vSokZCrVY1CBu3CRWNiSMWLY2VOILRBogtpVX31R2wxgnwfH6 P48OKUpCSvyl0zkR2ajJp7lBu3QDqwdDlcZGISOSme9zysoyUmqmmFLSmJNz4rugBU PKmKJ0tLBG4sw== Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:49:29 -0000 On 6/10/13 2:31 PM, Olle E. Johansson wrote: > > 10 jun 2013 kl. 18:53 skrev "Rosen, Brian" : > >> The URI to the cert used for signing comes in the signaling. >> >> Some folks on the list have proposed to use P-Asserted-Identity instead of From. Others want to be able to make the mechanism end to end (instead of SP to SP) and would prefer to base the sig on From rather than P-A-I. >> > I think we have to separate phone numbers (E.164) from e-mail style SIP uri's in this discussion. Just saying "The URI" is not enough. > > If I understand correctly this discussion is focused on the E.164 plan, so either Tel: uri's or just a phone number > that has some kind of relationship to the caller. In the case of e-mail style SIP uri's the relationship > is quite clear. I don't know if you literally meant tel URIs, or if you just meant tel URI syntax, possibly in a sip uri. For some reason I still don't grok many people seem to have an extreme phobia to TEL URIs. IMO they are the right thing to use if you don't know the domain that controls the number or if you don't care how the call is routed as long as it reaches something that is legitimately bound to that number. But it seems the fashion is most often to just paste the phone number onto any convenient domain that you hope has a clue how to handle phone numbers. I only bring this up because we may need to consider the implications of one or the other. IMO sip:+19785551212@example.com is a private uri belonging to example.com. It may be intended by example.com to represent a phone number, but I don't think anyone without special knowledge of example.com's policies can trust that assumption. Certainly example.com is free to use such a URI even if it has no rights to that phone number. Thanks, Paul > I think this is a reason why tel: was excluded from SIP identity - so we're looking to close that hole and in this work exclude the sip:/sips: URI's. > > /O > >> Brian >> >> On Jun 10, 2013, at 12:42 PM, "Dwight, Timothy M \(Tim\)" wrote: >> >>> I guess that works as long as the number blocks are different, and it's clear to the recipient whose public key he needs to use (the SP's or that of the PBX). How would he know? Trial and error? >>> >>> Also I don't know that it works in the "Vonage" scenario I referenced obliquely below. >>> >>> Tim >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, June 10, 2013 10:47 AM >>> To: Dwight, Timothy M (Tim) >>> Cc: philippe.fouquart@orange.com; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>> >>> Well, the PBX would have a sub delegation from the SP with a narrower scope. For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999. It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX. The PBX could sign with its 1300-1399 cert and the SP could sign with it's 1000-1999 cert. >>> >>> Brian >>> >>> On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" >>> wrote: >>> >>>> I suppose it's possible that both the service provider to which the number was assigned by the numbering plan authority, and the 'user' to whom that service provider assigned it, may have access to the associated private key. I am not comfortable with the security implications of that, though. And (to Brian's subsequent question) I'm not sure it works in all configurations, particularly I'm thinking of one in which the entity to whom the number was assigned by the numbering plan authority, not being the one providing PSTN ingress/egress services to it. If you follow the goings-on in the US FCC you're no doubt familiar with the recently-announced trial of that scenario. >>>> >>>> I wonder if we're trying to solve the wrong problem. There is already precedent for a 'user asserted' identity separate from a 'network asserted' identity. Could we use the same / similar mechanisms for both, but keep them separate? Or is there some underlying assumption that were the FROM header sufficiently trustworthy, there would be no further need for P-A-I? >>>> >>>> I think keeping them separate, at least might simplify the issues arising from too many entities needing access to the same private key. As they say, 3 people can keep a secret only if 2 are dead. >>>> >>>> Cheers, >>>> >>>> tim >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of philippe.fouquart@orange.com >>>> Sent: Monday, June 10, 2013 10:04 AM >>>> To: Rosen, Brian >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>> >>>> I assume the initial signing to be done by the endpoint, the pbx, which has authority over the full E.164 number. >>>> >>>> If the canonical form is incorrect (the international format is incorrect or the number is only provided in national format), I would have imagined that the intermediary would have to provide a correct canonical form and (?) resign. >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Monday, June 10, 2013 4:14 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>> >>>> I never thought about resigning. >>>> >>>> Whatever element signs has to be authoritative for the e.164. In your example, who do you think would do the initial signing and who would re-sign? >>>> >>>> Brian >>>> >>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>> >>>>> Thanks. Am I then right in rephrasing this as "it isn't going to be a problem if and only if the intermediary that corrects the canonical form is also able to [re]sign the [corrected] number?" >>>>> >>>>> For CgPNs, I guess this would work for a pbx using numbers under ranges of their service provider (or ported to it), but may not easily work for (more interesting) cases where the CgPN is completely unrelated with the call centre that initiated the call (eg a concierge service using their customer's individual number, the "Permitted spoofing" case). >>>>> >>>>> Regards, >>>>> >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>> >>>>> If both the endpoints and their SPs understand the rules, then they can generate the signature and check it. >>>>> Might have problems with intermediaries that couldn't do that unless the To was rewritten at some point. It would seem to me that in order to route these calls, that's what would have to happen unless you are using P-A-I passed between carriers to carry the decoded e.164. >>>>> >>>>> Brian >>>>> >>>>> >>>>> On Jun 10, 2013, at 9:06 AM, >>>>> wrote: >>>>> >>>>>>> Can we come up with examples where a canonicalized e.164 would NOT pass end to end? >>>>>> >>>>>> I'm not sure the following would fall into your category but in addition to prefixing thaty's already been mentioned, you may also have cases where the conversion from the dialing plan to the numbering plan involves a "degree of complexity" that cannot be expected from some endpoints because it is more complex than just "replace the national prefix, aka 'trunk prefix', with the relevant geographic country code" to get the full E.164 canonical form. (for example, supposing 0 as a national trunk code, some dialing plans map 0-XXX to _several_ geographic country codes +CC-XXX depending on the value of XXX). >>>>>> >>>>>> One simple way to support these formats is to allow the endpoint (eg a PBX) to always send +CC-XXX with one given CC (and therefore potentially incorrect canonical form) and correct it with the right mapping downstream. On may argue that it is a bit of a hack to make up for the lack of support of a phone-context by the endpoints, but you generally have to make do without it. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>> >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>>>> Of Rosen, Brian >>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>>> >>>>>> The fundamental idea that we have here is that you sign a set of information with a credential, and you pass the signature and a pointer to the credential in SIP signaling. >>>>>> >>>>>> We have some disagreements about what is signed. >>>>>> >>>>>> Henning has proposed that we canonicalize the From and To phone numbers, we include a timestamp and some form of call-id, possibly the INSIPID id. >>>>>> >>>>>> There are assertions that you can't use From/To, because middle boxes change them. Some have suggested using P-A-I and other headers instead. >>>>>> >>>>>> Hadriel wrote a draft about why From and To get modified: >>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>> >>>>>> After reading it, I am unclear if a canonicalized e.164 would make it through. The reasons given seem to indicate they would. They change domains, they change prefixes, but they don't seem to change the actual telephone number. >>>>>> >>>>>> Can we come up with examples where a canonicalized e.164 would NOT pass end to end? >>>>>> >>>>>> Brian >>>>>> >>>>>> ____________________________________________________________________ >>>>>> _ ____________________________________________________ >>>>>> >>>>>> 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>> >>>>> >>>>> _____________________________________________________________________ >>>>> _ ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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 dcrocker@bbiw.net Mon Jun 10 13:51: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 0D99221F9A05 for ; Mon, 10 Jun 2013 13:51:29 -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 bceT5eEWcrzv for ; Mon, 10 Jun 2013 13:51:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDD521E8085 for ; Mon, 10 Jun 2013 13:51:21 -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 r5AKoccD028252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 13:50:41 -0700 Message-ID: <51B63C1B.6040908@bbiw.net> Date: Mon, 10 Jun 2013 15:50:35 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.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.67]); Mon, 10 Jun 2013 13:50:42 -0700 (PDT) Cc: "'Rosen, Brian'" , Richard Shockey , "Olle E. Johansson" , stir@ietf.org, philippe.fouquart@orange.com Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:51:29 -0000 On 6/10/2013 2:59 PM, Henning Schulzrinne wrote: > legitimate spoofing Forgive me, but that oxymoronic phrase is not made reasonable by being so commonly used. Spoofing is unauthorized use. (Mirriam Webster: deceive, hoax.) There is not such thing as legitimate unauthorized use. This common mis-term has developed from a model that tries to impose constraints that are not valid, but rather highlight a variation from common practice. The reason for nagging about the phrase is that it gets people into the frame of mind of thinking that the common practice actually is the model. Then this inaccuracy is propagated out through the industry and the media. Most of the time that people use the term, they mean something like 'roaming use' or 'authorized third party use'. These aren't as catchy as legitimate spoofing, but that have the minor benefit of being accurate characterizations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pkyzivat@alum.mit.edu Mon Jun 10 13:55: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 DFF5221F995B for ; Mon, 10 Jun 2013 13:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.025, 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 cL-Lts5uztLE for ; Mon, 10 Jun 2013 13:55:34 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7557921F9631 for ; Mon, 10 Jun 2013 13:55:33 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id mbmR1l0041ap0As58kvY0N; Mon, 10 Jun 2013 20:55:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id mkvY1l01S3ZTu2S3ikvY8j; Mon, 10 Jun 2013 20:55:32 +0000 Message-ID: <51B63D44.30605@alum.mit.edu> Date: Mon, 10 Jun 2013 16:55:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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=1370897732; bh=UKOJd3DZuFjYy0lbuVAxkOxvwWFBQ+tmgCh+dHh/zyw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BOflB1cIEioIZTmvYpC/gG0XLN+G7utS6FShwOxa4JR849tVZUf7VBeRbSy/vtpuI k6WFM8I1Y4HNhoscS5oWWxJLkPBih1pLbvyl5Q+4/gooc8g16MQ8AVTCNd5RpuFHv2 eFl53iLE2hS2qDLtigQXtsy5uvByTp1DHD4g6YZj3MjLeHRP3l7vxTx4ZLnRJvYVR8 QjxW2vI5KKVZ9kvC/2mdxhblIdSspKE7E6smiCrFcT46dpmIRl61u3fFp1WyLJ+fsJ xj+di1yCRRAocziScclBTn1F4hal37KM5SeUAy86D2PqE490njnXWfKdaMrioudDVe TaSxS5pKWi4sQ== Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:55:39 -0000 On 6/10/13 2:58 PM, Rosen, Brian wrote: > Yeah, the basic variable length number is fairly easy to handle, but only > if you have the full number (no missing digits, other than perhaps the > country code). If you have the full e.164, no problem. Yes. The problem is if you have a number that has been prefixed in some way. If you know the number is from a fixed length numbering plan you can work right to left and figure out what the number is. But if there is an optional country code, or a variable length numbering plan that doesn't work. Thanks, Paul > All the existing number portability schemes have some kind of changeover > time measured in minutes, hours or days depending on the country. The > cut-over doesn't have to be instantaneous. Where there is a database, the > database could provide a validation ("is this specific TN still valid for > the range this cert covers?"). For countries that use forwarding schemes, > the original number holder would issue a cert to the gaining SP. > > To stop the problem, I think we need to at least start with verification > across SP boundaries and the termination. We want to get to the point > where an SP doesn't accept calls from a downstream SP that isn't > verifiable. Long term, that might be more of an audit between SPs, rather > than a 100% check, and I think we would see 100% verification at the end > of the call (ideally the end device, but perhaps the termination SP). > > Brian > > On 6/10/13 2:45 PM, "Olle E. Johansson" wrote: > >> >> 10 jun 2013 kl. 19:38 skrev "Richard Shockey" : >> >>> >>> Correct. In fact it would be useful to stop thinking about number >>> blocks at >>> all. LNP does create some issues but those can be dealt with as Brian >>> points out. It should come as no surprise that some NRA's are looking >>> at >>> the entire structure of E.164 allocation with an eye to single number >>> issuance in order to alleviate possible number exhaust issues, among >>> other >>> things. In the future it is not unreasonable to consider Phone >>> Numbers as >>> "domain names". >> If I'm correct a delegation in Germany more or less works that way. >> If I get +468964020 in Sweden, that's one single number. In Germany, >> it would be a prefix that can be extended arbitrary. >> >> We have to be careful with PKIs. If we're going down that path, the >> verification process will be painful. Switchover during the porting >> process >> will have to be instant - if we don't allow two certs for the same number. >> >> How many verifications can happen during one call from Alice to Bob? >> >> /O >> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Rosen, Brian >>> Sent: Monday, June 10, 2013 12:11 PM >>> To: Olle E. Johansson >>> Cc: philippe.fouquart@orange.com; stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >>> middle boxes? >>> >>> A proposal on the table is that the PKI for Telephone Numbers (TNs) >>> follows >>> the TN delegation chain. The root of trust is the national regulator, >>> or >>> some contractor to it. When numbers are delegated, a cert for that >>> delegation goes with it. Numbers can be subdelgated, certs with the sub >>> delegation follow. So you are "authoritative" for a number if you have >>> been >>> delegated (or sub delegated) that number, and have the cert for it. >>> Every >>> country has a delegation system for numbers. >>> >>> There is a complication with number portability that might cause a >>> specific >>> number in a range to no longer be valid, but there are simple solutions >>> to >>> that, depending on how a country implements number portability. >>> >>> Brian >>> >>> On Jun 10, 2013, at 11:54 AM, Olle E. Johansson wrote: >>> >>>> >>>> 10 jun 2013 kl. 17:25 skrev "Rosen, Brian" : >>>> >>>>> In order for that to work, the intermediary has to be authoritative >>>>> for the number. >>>>> Would that work? >>>> Have we defined "authoritative" for a specific number? >>>> >>>> /O >>>>> >>>>> Brian >>>>> >>>>> >>>>> On 6/10/13 11:04 AM, "philippe.fouquart@orange.com" >>>>> wrote: >>>>> >>>>>> I assume the initial signing to be done by the endpoint, the pbx, >>>>>> which has authority over the full E.164 number. >>>>>> >>>>>> If the canonical form is incorrect (the international format is >>>>>> incorrect or the number is only provided in national format), I >>>>>> would have imagined that the intermediary would have to provide a >>>>>> correct canonical form and >>>>>> (?) resign. >>>>>> >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Monday, June 10, 2013 4:14 PM >>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>> Cc: Rosen, Brian; stir@ietf.org >>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>>>>> other middle boxes? >>>>>> >>>>>> I never thought about resigning. >>>>>> >>>>>> Whatever element signs has to be authoritative for the e.164. In >>>>>> your example, who do you think would do the initial signing and who >>>>>> would re-sign? >>>>>> >>>>>> Brian >>>>>> >>>>>> On Jun 10, 2013, at 10:09 AM, philippe.fouquart@orange.com wrote: >>>>>> >>>>>>> Thanks. Am I then right in rephrasing this as "it isn't going to be >>>>>>> a problem if and only if the intermediary that corrects the >>>>>>> canonical form is also able to [re]sign the [corrected] number?" >>>>>>> >>>>>>> For CgPNs, I guess this would work for a pbx using numbers under >>>>>>> ranges of their service provider (or ported to it), but may not >>>>>>> easily work for (more interesting) cases where the CgPN is >>>>>>> completely unrelated with the call centre that initiated the call >>>>>>> (eg a concierge service using their customer's individual number, >>>>>>> the >>> "Permitted spoofing" case). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: Monday, June 10, 2013 3:28 PM >>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and >>>>>>> other middle boxes? >>>>>>> >>>>>>> If both the endpoints and their SPs understand the rules, then they >>>>>>> can generate the signature and check it. >>>>>>> Might have problems with intermediaries that couldn't do that unless >>>>>>> the To was rewritten at some point. It would seem to me that in >>>>>>> order >>>>>>> to route these calls, that's what would have to happen unless you >>>>>>> are using P-A-I passed between carriers to carry the decoded e.164. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> On Jun 10, 2013, at 9:06 AM, >>>>>>> wrote: >>>>>>> >>>>>>>>> Can we come up with examples where a canonicalized e.164 would >>>>>>>>> NOT pass end to end? >>>>>>>> >>>>>>>> I'm not sure the following would fall into your category but in >>>>>>>> addition to prefixing thaty's already been mentioned, you may also >>>>>>>> have cases where the conversion from the dialing plan to the >>>>>>>> numbering plan involves a "degree of complexity" that cannot be >>>>>>>> expected from some endpoints because it is more complex than just >>>>>>>> "replace the national prefix, aka 'trunk prefix', with the relevant >>> geographic country code" >>>>>>>> to get the full E.164 canonical form. (for example, supposing 0 as >>>>>>>> a national trunk code, some dialing plans map 0-XXX to _several_ >>>>>>>> geographic country codes +CC-XXX depending on the value of XXX). >>>>>>>> >>>>>>>> One simple way to support these formats is to allow the endpoint >>>>>>>> (eg a >>>>>>>> PBX) to always send +CC-XXX with one given CC (and therefore >>>>>>>> potentially incorrect canonical form) and correct it with the >>>>>>>> right mapping downstream. On may argue that it is a bit of a hack >>>>>>>> to make up for the lack of support of a phone-context by the >>>>>>>> endpoints, but you generally have to make do without it. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Philippe Fouquart >>>>>>>> Orange Labs Networks >>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>> >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>>> Behalf Of Rosen, Brian >>>>>>>> Sent: Friday, June 07, 2013 7:20 PM >>>>>>>> To: stir@ietf.org >>>>>>>> Subject: [stir] Can canonical phone numbers survive SBCs and other >>>>>>>> middle boxes? >>>>>>>> >>>>>>>> The fundamental idea that we have here is that you sign a set of >>>>>>>> information with a credential, and you pass the signature and a >>>>>>>> pointer to the credential in SIP signaling. >>>>>>>> >>>>>>>> We have some disagreements about what is signed. >>>>>>>> >>>>>>>> Henning has proposed that we canonicalize the From and To phone >>>>>>>> numbers, we include a timestamp and some form of call-id, possibly >>>>>>>> the INSIPID id. >>>>>>>> >>>>>>>> There are assertions that you can't use From/To, because middle >>>>>>>> boxes change them. Some have suggested using P-A-I and other >>>>>>>> headers >>> instead. >>>>>>>> >>>>>>>> Hadriel wrote a draft about why From and To get modified: >>>>>>>> http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt >>>>>>>> >>>>>>>> After reading it, I am unclear if a canonicalized e.164 would make >>>>>>>> it through. The reasons given seem to indicate they would. They >>>>>>>> change domains, they change prefixes, but they don't seem to >>>>>>>> change the actual telephone number. >>>>>>>> >>>>>>>> Can we come up with examples where a canonicalized e.164 would NOT >>>>>>>> pass end to end? >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> __________________________________________________________________ >>>>>>>> ______ _________________________________________________ >>>>>>>> >>>>>>>> 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, France Telecom - 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, France Telecom - Orange is not liable >>>>>>>> for messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ___________________________________________________________________ >>>>>>> ______ ________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>>>>> detruire ainsi que les pieces jointes. Les messages electroniques >>>>>>> etant susceptibles d'alteration, France Telecom - 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, France Telecom - Orange is not liable for >>>>>>> messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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, France Telecom - 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, France Telecom - Orange is not liable for >>>>>> messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 pkyzivat@alum.mit.edu Mon Jun 10 13:58: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 11D6B21F997D for ; Mon, 10 Jun 2013 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viSh6510S1Eh for ; Mon, 10 Jun 2013 13:58:02 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 161B221F9A1D for ; Mon, 10 Jun 2013 13:58:01 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id mjWq1l00T16LCl05Dky0vw; Mon, 10 Jun 2013 20:58:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id mky01l00X3ZTu2S3Sky0kN; Mon, 10 Jun 2013 20:58:00 +0000 Message-ID: <51B63DD8.6050808@alum.mit.edu> Date: Mon, 10 Jun 2013 16:58:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> In-Reply-To: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> 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=1370897880; bh=RxhvkSqj7zESG1WPkOlI0K5tLnwnspUNl91MUzM0m9g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AuucMzy83RVr5WNjbDekaQl0MjpJSgZYykChI0M+FQfGt5sWXoNIlanwd5hqCuewA cNtVsfcplamvIIspwMr6AaLAoi7PMzyrXzfm6rWou95BTDGTfxROD5eTca9995oBqk GzuZH5D7D32hYJivM2a7Do+B725LY34aE8oVS6u3Av2/2ocaMGnpnN4SW56DMY4X/1 fD6vq+fw3Ap+C2N3tHMnoPEH3nvCL3IqfnDb7OOK3/B6StdN9ks7K9RGsn5qGxTX9B R+aspxIOheuCNSl8EZXgVnR9thHsvovx2mhs0YsZnQotWe//8TzEH6Un+9o+vVUcUW XGarY/r9qhF9A== Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 20:58:08 -0000 On 6/10/13 4:47 PM, Rosen, Brian wrote: > The proposed basic mechanism doesn't depend on a database of certs. The URL to the cert accompanies the signature. "The proposed basic mechanism"??? Did I miss something? Where is this proposal? Thanks, Paul From dhc2@dcrocker.net Mon Jun 10 13:59: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 7B8F221F86C0 for ; Mon, 10 Jun 2013 13:59: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 vER6MlAb+Vso for ; Mon, 10 Jun 2013 13:58:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 847B621F843F for ; Mon, 10 Jun 2013 13:58:55 -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 r5AKwnWS028492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 13:58:52 -0700 Message-ID: <51B63E06.9040705@dcrocker.net> Date: Mon, 10 Jun 2013 15:58:46 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> In-Reply-To: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> 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, 10 Jun 2013 13:58:53 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach 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, 10 Jun 2013 20:59:00 -0000 On 6/10/2013 3:47 PM, Rosen, Brian wrote: > ENUM, as originally envisioned, was a public database. That is a complete non-starter. > > ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work. > > What works is number delegation, and centralized databases like the US NPAC. Brian, One of the things that would be especially helpful is to have consensus on some exemplar use cases that would aid in understanding which suggestions might be viable and which might not be. It's clear that a few of you have a shared model for this activity, but unfortunately it hasn't been externalized, making it accessible to the rest of the IETF community. So as of now, debating whether a DNS public-key mechanism is viable or can't be a debate. Only one side knows the operational criteria. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Mon Jun 10 14:00: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 4167621E80AB for ; Mon, 10 Jun 2013 14:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 eU0-mTgwc1Lw for ; Mon, 10 Jun 2013 14:00:01 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0361221E80A3 for ; Mon, 10 Jun 2013 13:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370897911; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=pGkq09Mt0A VnC90OwdvvlZJlyMMqak5AUai2TSNyiFA=; b=YGvjeNsWu1s0El226eYjwLcbCm +DNzkDpp3p2JNABfT2nEhBsoBG5Wlbynazl7tPJ06ku7hZ8AkY75SBD26OoA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20801554; Mon, 10 Jun 2013 16:58:30 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 16:59:24 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 16:59:19 -0400 From: "Rosen, Brian" To: Dave Crocker Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABKAAgAAYjACAABLAAIAAFJwAgAAOT4CAAAJxgA== Date: Mon, 10 Jun 2013 20:59:19 +0000 Message-ID: <5D2DEEA6-9D29-416E-BE8C-BC95C1B03F60@neustar.biz> References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> <51B63C1B.6040908@bbiw.net> In-Reply-To: <51B63C1B.6040908@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 0muonI5yxxq7De37qFopQA== Content-Type: text/plain; charset="us-ascii" Content-ID: <7B738F891D33994EA89F3C30495A12F0@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "Olle E. Johansson" , Richard Shockey , "stir@ietf.org" , "Rosen, Brian" , Henning Schulzrinne Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:00:05 -0000 If a service let's a doctor place a call from his mobile, that appears to c= ome from his office, then the source of the call is not actually the source= of the call. If the doctor wants that, and he and his service provider is= okay with it, he can permit it, but it's still a form of intentional misdi= rection. If he hid the source, that would be one thing, but if he substitu= tes his office for his mobile, that is identifier substitution, i.e. spoofi= ng. I don't really care what we call it, but it is substituting the real identi= fier. The only difference between the service doing it and a scammer doin= g it is permission. Brian On Jun 10, 2013, at 4:50 PM, Dave Crocker wrote: > On 6/10/2013 2:59 PM, Henning Schulzrinne wrote: >> legitimate spoofing >=20 >=20 > >=20 > Forgive me, but that oxymoronic phrase is not made reasonable by being so= commonly used. Spoofing is unauthorized use. (Mirriam Webster: deceive, h= oax.) There is not such thing as legitimate unauthorized use. >=20 > This common mis-term has developed from a model that tries to impose cons= traints that are not valid, but rather highlight a variation from common pr= actice. >=20 > The reason for nagging about the phrase is that it gets people into the f= rame of mind of thinking that the common practice actually is the model. T= hen this inaccuracy is propagated out through the industry and the media. >=20 > Most of the time that people use the term, they mean something like 'roam= ing use' or 'authorized third party use'. These aren't as catchy as legiti= mate spoofing, but that have the minor benefit of being accurate characteri= zations. >=20 > >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Mon Jun 10 14:07: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 8BCD521F8EBC for ; Mon, 10 Jun 2013 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=0.023, 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 MojKnxaCS2Wz for ; Mon, 10 Jun 2013 14:07:16 -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 A403621F8B90 for ; Mon, 10 Jun 2013 14:07:16 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id mhKG1l00616LCl05Al7GVs; Mon, 10 Jun 2013 21:07:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ml7F1l01L3ZTu2S3Sl7FsX; Mon, 10 Jun 2013 21:07:16 +0000 Message-ID: <51B64002.7070308@alum.mit.edu> Date: Mon, 10 Jun 2013 17:07:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <51B23B0A.7040608@alum.mit.edu> <0B5B43BD-7681-4BE5-9857-94F307389C81@oracle.com> In-Reply-To: <0B5B43BD-7681-4BE5-9857-94F307389C81@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=1370898436; bh=5Mkmpqn9TchYtjAy350i+8e70zFZ3L0kgQ5ceE8fQEs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fj5IRXWAyc14wGeq8lMK9sqq9s9XWtYSfUnGMw+dvNYFcTxn2Aas5HT8N3ocRwesN ZrfzpWFwgQsxdReRWid3jBD0gn3R58GmNbXRxxES0PPaAuS9h4E1QMsqOaUnMJu28U yh4gfxvY0G+ZbRPwDGkk8lChSKiCqlEkHHTIwgFDOr/BJjOE1tSQ9BJmuS5lw2cMmi EOHTPr9SDgDiKm9ZDAz0N7P2I0C687PecIr5v4+WxaG1liTBTy1c3iNecqHyexhcZp VLJT6uAt2LB4SoV+lbLxZDhSEfWag7Yx/sKaRuTWWZNIvCH0CwBm5Cdb3kKDyIdKh1 WcvICuZkpSlDQ== Cc: stir@ietf.org Subject: Re: [stir] Call Forward/Follow-me X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:07:22 -0000 Hadriel, You are right. I wasn't thinking clearly. What H-I *can* do is identify who forwarded a call. This might be important to the forwardee - he might not want to answer unless it is from someone he knows. So H-I *can* serve as an alternative to an intermediary changing From or To when forwarding. (But it then leaves the recipient with difficulty in deciding which number it will display.) Thanks, Paul On 6/7/13 4:10 PM, Hadriel Kaplan wrote: > > I'm getting confused by this thread. > History-Info (or Diversion) is only useful to know the original *called* destination party, not *calling* source party. > > I.e., if the To-username gets changed by the PBX, Hist-info might tell you what it used to be... if the req-uri matched the To, and the PBX does Hist-Info, and all downstream devices pass it on, and if the final UAS could decipher which Hist-info to look at, and if the stars aligned. > > But if the From username got changed nothing will tell you what it used to be. I think Brian was arguing the From should be changed by the PBX to be the new source of the new call, namely the PBX's main number or the To-number being forwarded from - because otherwise it's spoofing the From for this "new" call - but I don't think it should change the From because I contend it's not spoofing, but just routing the same call as a B2BUA. > > -hadriel > > > On Jun 7, 2013, at 3:56 PM, Paul Kyzivat wrote: > >> On 6/7/13 2:23 PM, Alan Johnston wrote: >>> I think that History-Info should be the solution going forward, >>> certainly for SIP networks. >> >> I expect that there will be a variety of "solutions". >> We aren't obligated to mandate one. Its only necessary to ban spoofing, and let people decide which alternative they want to use. >> >> If H-I was deployed across the full range of equipment out there, I'd expect that correct reporting of calling party would be very spotty. >> >> Now that calling is typically cheap enough that most people don't think about it, a simple solution to forwarding is 3xx, and to transfer is basic REFER. Those will get the calling party right. (Except in cases where you *want* the identify of the intermediary to be displayed. And that is the easy case.) >> >> Thanks, >> Paul >> >>> - Alan - >>> >>> >>> On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian >> > wrote: >>> >>> A problem that has been noted is PBXs and other services that >>> implement Call Forward and Follow-me by spoofing From to be the >>> original caller when they originate a call from the PBX to the >>> ultimate destination. They do this so that the called party sees >>> the original caller when they get the call. >>> >>> If we outlaw spoofing, these services wouldn't be able to do that. >>> They would have to use History or other headers to pass the >>> original calling party number. >>> >>> I believe that we can't continue to allow this kind of spoofing. >>> There are other headers which are appropriate for use. >>> >>> One of the arguments given is that in older systems such as POTS or >>> 2G/3G, there is no way to get caller ID to show data from the other >>> headers. I think we have to accept such limitations. Newer systems >>> would not have that problem of course. >>> >>> While it may be unfortunate that something like forward or follow-me >>> doesn't work as well as it did, I think that it's the right tradeoff. >>> >>> Please note that there are another class of calling party number >>> spoofing circumstances we CAN do something about. Suppose a doctor >>> wants to place a call on her mobile that appears to come from her >>> office number. In that case the doctor can authorize the service >>> that arranges that call. They can get the cert for the office >>> number and authorize the service to place calls with that number by >>> giving them a cert for that authorization. This also works for, as >>> an example, a call center placing calls for an enterprise. >>> >>> The difference is, of course, that the "spoofed" number is a number >>> delegated to the entity spoofing, rather than the forward/follow me >>> case where the spoofed number is the calling party and the entity >>> spoofing is authorized by the called party. >>> >>> 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 > > From stephen.farrell@cs.tcd.ie Mon Jun 10 14:11: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 5FE0B21F9648 for ; Mon, 10 Jun 2013 14:11:19 -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 E8fAdvKwJr2S for ; Mon, 10 Jun 2013 14:11:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 74D3721F8F5C for ; Mon, 10 Jun 2013 14:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D5E43BE8B; Mon, 10 Jun 2013 22:10:47 +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 a00boFlZwFue; Mon, 10 Jun 2013 22:10:46 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.23.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 25D1CBE70; Mon, 10 Jun 2013 22:10:46 +0100 (IST) Message-ID: <51B640D5.4000406@cs.tcd.ie> Date: Mon, 10 Jun 2013 22:10:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> In-Reply-To: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:11:20 -0000 On 06/10/2013 09:47 PM, Rosen, Brian wrote: > ENUM does not exist. > > We have an RFC, but we have essentially no deployment. Fair point. OTOH, neither is there a TN-delegating RFC 5280 based PKI deployed. I couldmaybe buy that there'd be political issues with an ENUM structured DNS approach. I've no idea why, nor if that'd be fatal. > ENUM, as originally envisioned, was a public database. That is a complete non-starter. Why? I mean for this application, not general phone numbers. For this, I'd just want the signer's public key at the right place in the DNS, where "right place" is maybe the delegation point (sorry if that's the wrong term). Say if the caller's phone is +353-1-896-1234 then the public key might be at +353-1-896 in the DNS so my call from TCD to somewhere can be signed by TCD. And again, I'm not advocating for such a thing, just asking why its broken. > ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work. > > What works is number delegation, and centralized databases like the US NPAC. > > The proposed basic mechanism doesn't depend on a database of certs. The URL to the cert accompanies the signature. Sentences like that last fill me with worry. I just don't think the PKI for that is at all easy, if its to be standardised and work well. The RPKI has been a bunch of work and this'd be only very slightly less IMO. Cheers, S. > > One of the proposed mechanisms for handling the so-called "out of band" mechanism that gets around SS7 links and SPs that don't preserve the signed information does depend on such a database. I think that is a weakness. There are ways to create such a database which do not depend on DNS. > > Brian > On Jun 10, 2013, at 4:21 PM, Stephen Farrell wrote: > >> >> Hi >> >> On 06/07/2013 08:17 PM, Dave Crocker wrote: >>> (Just to be clear, I'm suggesting consideration of an approach; I'm not >>> sure it's the best one and I'm therefore not pushing for its adoption, >>> merely that it be explored.) >>> >>> Anyone can sign. They sign with a domain they own. So the signature >>> goes with the operator, not with the content (number, message, whatever.) >> >> I'd also like to understand the argument here as to whether a DKIM >> like approach to public key retrieval is good enough or not for this >> application. (Note that this is orthogonal to any discussion about a >> DKIM-like or 4474-like signature format, I'm just asking about public >> key retrieval now.) >> >> As with everything, I don't need to understand it now, but I do think >> that a bunch of folks here are making assumptions about PKI that might >> turn out to be a large amount of work later, e.g. that TN delegation >> specific certificate chains exist, can be found and can be verified >> efficiently. >> >> One could easily argue that since ENUM exists and DKIM key records >> exist (*) a DNS lookup could be the way to get signers' public keys >> without requiring any 5280 processing at all at the signer or verifier. >> >> One could further argue that that'd be sufficiently "secure" even >> without DNSSEC, in that it'd be enough to mitigate your robocaller >> issues on the basis that those robocallers aren't gonna MITM or >> poison DNS at the verifier. >> >> A similar argument was made for DKIM: since a bad DKIM signature is >> the same as no signature on a mail message, there's no need to require >> DNSSEC to get DKIM started. >> >> While its not quite the same in this context, it may be that one >> could argue that a reasonable threat model would not require the >> signature verifier (someone/thing en-route to the callee) to >> strongly verify the signing public key. >> >> (Ok, I can't resist adding a feature:-) If the DKIM key selector >> were modified (to put it in the key value) then you might also get >> some level of traceability in that one could trawl the DNS for >> signer's public keys. I don't know if that'd be good or bad. >> >> Anyway, for now, can we make sure this gets discussed before we >> plump for any specific key management solution? That could be now, >> or at a DISPATCH session or BoF or after a WG is chartered, I >> don't mind, so long as it is properly considered. >> >> S. >> >> (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. >> For the present discussion, just assume that the keys are in the >> "correct" kind of RR. >> > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From york@isoc.org Mon Jun 10 14:13: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 32A4A21F8749 for ; Mon, 10 Jun 2013 14:13:41 -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 FawEAPnY9jgt for ; Mon, 10 Jun 2013 14:13:36 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id B564A21F8628 for ; Mon, 10 Jun 2013 14:13:35 -0700 (PDT) Received: from mail164-db9-R.bigfish.com (10.174.16.243) by DB9EHSOBE023.bigfish.com (10.174.14.86) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 21:13:34 +0000 Received: from mail164-db9 (localhost [127.0.0.1]) by mail164-db9-R.bigfish.com (Postfix) with ESMTP id A556A1C0100; Mon, 10 Jun 2013 21:13:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch177df4h17326ah8275fh8275bh8275dhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail164-db9 (localhost.localdomain [127.0.0.1]) by mail164-db9 (MessageSwitch) id 1370898812149235_17974; Mon, 10 Jun 2013 21:13:32 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.251]) by mail164-db9.bigfish.com (Postfix) with ESMTP id 1F2A7A0051; Mon, 10 Jun 2013 21:13:32 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Jun 2013 21:13:31 +0000 Received: from BL2PRD0610MB374.namprd06.prod.outlook.com ([169.254.5.235]) by BL2PRD0610HT003.namprd06.prod.outlook.com ([10.255.101.38]) with mapi id 14.16.0311.000; Mon, 10 Jun 2013 21:13:30 +0000 From: Dan York To: "Rosen, Brian" , Dave Crocker Thread-Topic: Alternative wording for "legitimate spoofing" - Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZhxTdDF03iKwj0e3WIPP666+Y5kvboeA///A5IA= Date: Mon, 10 Jun 2013 21:13:29 +0000 Message-ID: In-Reply-To: <5D2DEEA6-9D29-416E-BE8C-BC95C1B03F60@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B8072E1774AFE4CB081B8AE77E20BD2@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "philippe.fouquart@orange.com" , Henning Schulzrinne , "Olle E. Johansson" , "stir@ietf.org" , Richard Shockey Subject: [stir] Alternative wording for "legitimate spoofing" - Re: Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:13:43 -0000 On 6/10/13 4:59 PM, "Rosen, Brian" wrote: >If a service let's a doctor place a call from his mobile, that appears to >come from his office, then the source of the call is not actually the >source of the call. If the doctor wants that, and he and his service >provider is okay with it, he can permit it, but it's still a form of >intentional misdirection. If he hid the source, that would be one thing, >but if he substitutes his office for his mobile, that is identifier >substitution, i.e. spoofing. > >I don't really care what we call it, but it is substituting the real >identifier. The only difference between the service doing it and a >scammer doing it is permission. Yes, but I agree with Dave that here is a place where words *do* matter. Beyond the call centers and doctor example, there is also a part of the industry building applications and other forms of automation that do legitimately operate on behalf of the original caller, typically under contract with that original caller. There's a great deal of innovation and activity happening in this space. I really don't want to send us down a grammatical rathole, but to me, "legitimate spoofing" casts a negative tone to this area and would be good to be avoided. Other options could be: - authorized third party use - delegated calls/calling (thinking of the call center / app usage) - roaming use (thinking of the doctor) - authorized identifier substitution - authorized identifier replacement As Dave said in his nag, none of these are as catchy as "legitimate spoofing", but I do think we should decide on one (of these above or that someone else has) that we use. My 2 cents, Dan > >Brian >On Jun 10, 2013, at 4:50 PM, Dave Crocker wrote: > >> On 6/10/2013 2:59 PM, Henning Schulzrinne wrote: >>> legitimate spoofing >>=20 >>=20 >> >>=20 >> Forgive me, but that oxymoronic phrase is not made reasonable by being >>so commonly used. Spoofing is unauthorized use. (Mirriam Webster: >>deceive, hoax.) There is not such thing as legitimate unauthorized use. >>=20 >> This common mis-term has developed from a model that tries to impose >>constraints that are not valid, but rather highlight a variation from >>common practice. >>=20 >> The reason for nagging about the phrase is that it gets people into the >>frame of mind of thinking that the common practice actually is the >>model. Then this inaccuracy is propagated out through the industry and >>the media. >>=20 >> Most of the time that people use the term, they mean something like >>'roaming use' or 'authorized third party use'. These aren't as catchy >>as legitimate spoofing, but that have the minor benefit of being >>accurate characterizations. >>=20 >> >>=20 >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ From stephen.farrell@cs.tcd.ie Mon Jun 10 14: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 8BEA421F8F5C for ; Mon, 10 Jun 2013 14:14:24 -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 Y9mt4GjJyO+a for ; Mon, 10 Jun 2013 14:14:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63A21F86D3 for ; Mon, 10 Jun 2013 14:14:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3FCEEBE7C; Mon, 10 Jun 2013 22:13:56 +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 PznptjehUXQS; Mon, 10 Jun 2013 22:13:55 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.23.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65840BE7B; Mon, 10 Jun 2013 22:13:55 +0100 (IST) Message-ID: <51B64193.6050207@cs.tcd.ie> Date: Mon, 10 Jun 2013 22:13:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <51B639F8.9020600@dcrocker.net> In-Reply-To: <51B639F8.9020600@dcrocker.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , Dave Crocker , "stir@ietf.org" Subject: Re: [stir] selector naming (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:14:24 -0000 On 06/10/2013 09:41 PM, Dave Crocker wrote: > On 6/10/2013 3:21 PM, Stephen Farrell wrote: >> (Ok, I can't resist adding a feature:-) If the DKIM key selector >> were modified (to put it in the key value) then you might also get >> some level of traceability in that one could trawl the DNS for >> signer's public keys. I don't know if that'd be good or bad. > > This is a very specialized topic, given the overall posting, but I > thought it worth noting for the archive that while I had missed the > threat vector that predictable selectors pose, operators have not. > > At an anti-abuse meeting last week, they were discussing selector naming > schemes (in support of rotating keys under different selectors) that are > less predictable, to make trolling more effort. Fair point. OTOH, for this application, if we're after "signed by someone delegated to look after that part of the number space" then maybe having the keys be findable could be a benefit. But yes, very much a detail. S. > > d/ > From brian.rosen@neustar.biz Mon Jun 10 14: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 C212A21F9A3A for ; Mon, 10 Jun 2013 14:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 Z8fdC-88sdJS for ; Mon, 10 Jun 2013 14:26:25 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 824E021F9A38 for ; Mon, 10 Jun 2013 14:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370899759; x=1686258144; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=eQdijI+c3v UDQNH3AP0NBB+aTpDIfwYJc6QUxbmgdQ8=; b=oH+Ef1/wjYm1lAdQLkDTLXOcHB QOwNS3k/7ECEgmMbBtlYaD/nADyBoMLSnvPqDIqbx61zRdddqsijfOQoKZtQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24904724; Mon, 10 Jun 2013 17:29:18 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 17:26:16 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 17:26:15 -0400 From: "Rosen, Brian" To: "" Thread-Topic: DKIM-like key mgmt approach Thread-Index: AQHOZh1WO6SdzeTUo0uhykTBqzt8o5kvuRgA Date: Mon, 10 Jun 2013 21:26:15 +0000 Message-ID: <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> In-Reply-To: <51B63E06.9040705@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: RmY49HahIcrWjEmegUj20Q== Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:26:29 -0000 Fair criticism, although use cases wouldn't help understanding why ENUM is = not likely to work as part of the solution. Here is a start 1. A robocaller on a SIP network places calls to unwitting victims where th= ey intentionally obscure, drop or spoof the calling party number. There i= s a SIP connection from end to end, although there are very often several s= ervice providers in the path. The SP to which the robocaller is directly c= onnected permits this use, perhaps by turning a blind eye to it rather than= expressly countenancing it. Assume that the service provider at the end o= f the call would be willing to check validity of the calling party identity= . 2. A perpetrator places a call to a victim using the (spoofed) telephone nu= mber of the bank. CallerId appears to be the bank. The fisher claims the = victim is the subject of an identity theft and the caller will help, but th= ey need some verification information from the victim. "If you could just = confirm your social security number and date of birth please=85". Also SIP= end to end. 3. A kid with a script fakes a call to the emergency number (1-1-2, 9-1-1, = =85) with a spoofed From and claims they see many armed intruders in a neig= hbors house. Call out the SWAT team. Also SIP end to end. 4. The above 3 cases where the called party is not on a SIP device, but the= re is a SIP path from the calling party to a vigilant service provider who = is willing to verify the identity of the calling party. 5. The above 3 cases where the called party is on a SIP device (or its SP i= s SIP connected) but there are one or more hops where the identity authenti= cation mechanism fails (that is, the identity or the identity checking info= rmation is dropped). This might be an SS7 hop for example. 6. The originating and terminating end devices are SIP connected, and desir= e to authenticate the caller, but there are one or more hops (possibly incl= uding the first or last hops) where the identity authentication mechanism i= s dropped. Brian On Jun 10, 2013, at 4:58 PM, Dave Crocker wrote: > On 6/10/2013 3:47 PM, Rosen, Brian wrote: >> ENUM, as originally envisioned, was a public database. That is a comple= te non-starter. >>=20 >> ENUM tried to evolve to a private database, but in most places, it was n= ot possible to organize the relationships to make it work. >>=20 >> What works is number delegation, and centralized databases like the US N= PAC. >=20 >=20 > Brian, >=20 > One of the things that would be especially helpful is to have consensus o= n some exemplar use cases that would aid in understanding which suggestions= might be viable and which might not be. >=20 > It's clear that a few of you have a shared model for this activity, but u= nfortunately it hasn't been externalized, making it accessible to the rest = of the IETF community. >=20 > So as of now, debating whether a DNS public-key mechanism is viable or ca= n't be a debate. Only one side knows the operational criteria. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From brian.rosen@neustar.biz Mon Jun 10 14:40: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 02DD321F901F for ; Mon, 10 Jun 2013 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 01TUjDE8hFZl for ; Mon, 10 Jun 2013 14:40:43 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6521F9005 for ; Mon, 10 Jun 2013 14:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370900611; x=1686258144; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=xDSGLditZv qiT/chQzgozvW1b3HymG/XxCMCq4XsMew=; b=MRj0rVH2EbqdU2gZ9k6Y+f6Xeu 5nPCVv7kknZjnUDb/GGE3E/nXn8t99BeuYFinaciHtagDP7hSrkRIuJd08WA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24905381; Mon, 10 Jun 2013 17:43:30 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 17:40:28 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 17:40:22 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvQaA Date: Mon, 10 Jun 2013 21:40:22 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B640D5.4000406@cs.tcd.ie> In-Reply-To: <51B640D5.4000406@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fxgjd8KrWoiB508f1m+/BA== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:40:48 -0000 I spent several years of my life flogging ENUM. It has failed, pretty much across the board. See the TERQ discussion for a lot of the reasons. See inline for more On Jun 10, 2013, at 5:10 PM, Stephen Farrell wrote: >=20 >=20 > On 06/10/2013 09:47 PM, Rosen, Brian wrote: >> ENUM does not exist. >>=20 >> We have an RFC, but we have essentially no deployment. >=20 > Fair point. OTOH, neither is there a TN-delegating RFC 5280 > based PKI deployed. >=20 > I couldmaybe buy that there'd be political issues with an ENUM > structured DNS approach. I've no idea why, nor if that'd be > fatal. ENUM depended on several things that turned out to be very hard to arrange: 1. The global root problem. Using the ITU was problematic, but having said= that, there isn't any other obvious answer either 2. Carrier cooperation. Hasn't happened. 3. Regulator pressure. Hasn't happened. Actually the opposite - the regul= ator had to ask the ITU to delegate the country code. Never happened. >=20 >> ENUM, as originally envisioned, was a public database. That is a comple= te non-starter. >=20 > Why? I mean for this application, not general phone numbers. Because no one wants ANY meta information about a number to actually be pub= lic. =20 That is a consensus among the service providers and the regulators. Even m= ost privacy advocates say that. >=20 > For this, I'd just want the signer's public key at the right > place in the DNS, where "right place" is maybe the delegation > point (sorry if that's the wrong term). Say if the caller's > phone is +353-1-896-1234 then the public key might be at > +353-1-896 in the DNS so my call from TCD to somewhere can > be signed by TCD. Number delegation doesn't work the way DNS works. It's a bad fit. You are much better off just querying a flat database. We can do that. We = have that in many countries. >=20 > And again, I'm not advocating for such a thing, just asking > why its broken. See TERQ >=20 >> ENUM tried to evolve to a private database, but in most places, it was n= ot possible to organize the relationships to make it work. >>=20 >> What works is number delegation, and centralized databases like the US N= PAC. >>=20 >> The proposed basic mechanism doesn't depend on a database of certs. The= URL to the cert accompanies the signature. >=20 > Sentences like that last fill me with worry. I just don't think > the PKI for that is at all easy, if its to be standardised and > work well. The RPKI has been a bunch of work and this'd be only > very slightly less IMO. We have some advantages here, mostly that we have a big enough problem that= workable solutions may be able to be deployed, where before they weren't. = However, we can't erase history, nor can we change fundamental things abou= t how the number space is organized. We can augment it, but not change it.= That's what we propose. This is going to be a bunch of work to deploy. No question about it. We'r= e looking for a path we think will succeed. =20 Brian= From york@isoc.org Mon Jun 10 14: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 0FC2C21F9A8F for ; Mon, 10 Jun 2013 14:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 w7GViuytMtnr for ; Mon, 10 Jun 2013 14:48:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4121F962A for ; Mon, 10 Jun 2013 14:48:08 -0700 (PDT) Received: from mail100-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE013.bigfish.com (10.3.207.135) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Jun 2013 21:48:07 +0000 Received: from mail100-am1 (localhost [127.0.0.1]) by mail100-am1-R.bigfish.com (Postfix) with ESMTP id A5FE03600E1; Mon, 10 Jun 2013 21:48:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1370900886546182_2702; Mon, 10 Jun 2013 21:48:06 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.253]) by mail100-am1.bigfish.com (Postfix) with ESMTP id 82A4234004E; Mon, 10 Jun 2013 21:48:06 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Jun 2013 21:48:05 +0000 Received: from BL2PRD0610MB374.namprd06.prod.outlook.com ([169.254.5.235]) by BL2PRD0610HT003.namprd06.prod.outlook.com ([10.255.101.38]) with mapi id 14.16.0311.000; Mon, 10 Jun 2013 21:48:05 +0000 From: Dan York To: Stephen Farrell , "Rosen, Brian" Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh8xX8hPsF3xCUSrF0FUXsSvI5kvORGA Date: Mon, 10 Jun 2013 21:48:04 +0000 Message-ID: In-Reply-To: <51B640D5.4000406@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <59A4F8CA84F0FE428844A136B60392AF@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Dave Crocker , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:48:16 -0000 On 6/10/13 5:10 PM, "Stephen Farrell" wrote: >> ENUM, as originally envisioned, was a public database. That is a >>complete non-starter. > >Why? I mean for this application, not general phone numbers. > >For this, I'd just want the signer's public key at the right >place in the DNS, where "right place" is maybe the delegation >point (sorry if that's the wrong term). Say if the caller's >phone is +353-1-896-1234 then the public key might be at >+353-1-896 in the DNS so my call from TCD to somewhere can >be signed by TCD. So in this scenario, the signer might be the corporate PBX, with the base phone number at +353-1-896? How does the validating recipient system know to query for only that part of the phone number? Would it need to try for the full phone number first, then smaller parts of the number until it got back an answer? (This would seem to introduce latency and added DNS queries.) Or did I miss somewhere in the 100+ messages over the last few days a suggestion for a way to tie a part of a number to what to look up? >And again, I'm not advocating for such a thing, just asking >why its broken. I'm sure someone like Brian or Richard Shockey could give you a long list of reasons ENUM failed. A fundamental one to me is that a public ENUM database gave carriers and everyone access to all the meta information about what numbers were under a carrier's responsibility. And it provided a wonderful way for spammers to walk the DNS tree and build up a nice list of everyone to bombard with telemarketing calls. (And there are a couple of scripts out there that do exactly that.) I realize you are not suggesting ENUM for the general case of phone numbers, but even in an abbreviated form I think it would probably expose far more info publicly than most people are comfortable with. My 2 cents, Dan From dcrocker@bbiw.net Mon Jun 10 14:53: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 14E4C21F9A24 for ; Mon, 10 Jun 2013 14:53:44 -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.600, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=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 6ZHTCaEicezF for ; Mon, 10 Jun 2013 14:53:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7535921F9A25 for ; Mon, 10 Jun 2013 14:53:38 -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 r5ALrVJs029751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 14:53:34 -0700 Message-ID: <51B64AD8.6000402@bbiw.net> Date: Mon, 10 Jun 2013 16:53:28 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> In-Reply-To: <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Mon, 10 Jun 2013 14:53:35 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 21:53:44 -0000 On 6/10/2013 4:26 PM, Rosen, Brian wrote: > 6. The originating and terminating end devices are SIP connected, and desire to authenticate the caller, but there are one or more hops (possibly including the first or last hops) where the identity authentication mechanism is dropped. Brian, Thanks for circulating the cases. (Purely OT: The form of Cases 4 and 5 was interesting, by way of suggesting that you've been spending far too much time around patents...) I assume that simplistic diagrams of actors for these cases is something like: PSTN>SIP G/W -->+ +-> SIP>PSTN GW | | +-> SIP Op1..SIP OpN -+ | | Caller SIP UA ->+ +- Callee SIP UA (However I thought that SIP allows true peer-peer exchanges, too, without mediation by an operator?) Using "signing" and "verifying" as generic terms here, who can do each? If any SIP-related actor is prohibited, then why? For example, I'd assume that a Callee SIP UA could do verification according to the architecture, even if that's not expected to be a typical operational mode. If not, why not? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Mon Jun 10 15:07: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 34E7321F9ADE for ; Mon, 10 Jun 2013 15:07:56 -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 dveTD4EzrJYZ for ; Mon, 10 Jun 2013 15:07:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C76221F9AD1 for ; Mon, 10 Jun 2013 15:07:47 -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 r5AM7h6R030076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 15:07:46 -0700 Message-ID: <51B64E2C.8000907@dcrocker.net> Date: Mon, 10 Jun 2013 17:07:40 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> <51B63C1B.6040908@bbiw.net> <5D2DEEA6-9D29-416E-BE8C-BC95C1B03F60@neustar.biz> In-Reply-To: <5D2DEEA6-9D29-416E-BE8C-BC95C1B03F60@neustar.biz> 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, 10 Jun 2013 15:07:46 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? 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, 10 Jun 2013 22:07:56 -0000 On 6/10/2013 3:59 PM, Rosen, Brian wrote: > If a service let's a doctor place a call from his mobile, that > appears to come from his office, That's a reasonable description of many people's views about a phone number, but of course it's now quite wrong and has been for many years. This demonstrates the difference between "common" and "required". Phone numbers no longer are required to refer to a device, a geographic location, a network topological location or a service operator. They've become a random string, whose meaning is established by use and entry into a database. (Let's skip over the oddness of my reciting this to someone at a company that makes this fact workable.) I made many 'local' phone calls last week, while I was in Austria. By local I mean even the phone company thought I was 'home' in California. They provide a WiFi-based Internet path for calls to/from my mobile phone and therefore don't care at all where I am physically. (And my carrier charges according to home access.) The phone number refers to the SIM card, in this case. Had I made a call from a phone with a different SIM card but caused caller ID to show my original number, that would be mechanically interesting, but not at all interesting for the callee. They'd see my number and I'm the one calling. > I don't really care what we call it, but it is substituting the real > identifier. The only difference between the service doing it and a > scammer doing it is permission. "real" identifier? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Mon Jun 10 15:10: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 DF18F21E8056 for ; Mon, 10 Jun 2013 15:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=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 PGBSVlCPXxHM for ; Mon, 10 Jun 2013 15:10:06 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B212A11E80BA for ; Mon, 10 Jun 2013 15:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370902380; x=1686258144; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=aZZB3+vJhR Za9cj6B/P00TBgGt3tDTVNKkqCNlEVTKQ=; b=nkl31tiqgsxh/FC2RvVotT7ms1 a1vfTYhZnr5SshzqcFNsnJxI5xiqPkbWvlMSP8wD2GRVmVjwKymjvrD0APow== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24906518; Mon, 10 Jun 2013 18:12:59 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 18:09:58 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 18:09:55 -0400 From: "Rosen, Brian" To: Dave Crocker Thread-Topic: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) Thread-Index: AQHOZiT6vkcreS1Fq0G6ZmX7V037yZkvxTuA Date: Mon, 10 Jun 2013 22:09:54 +0000 Message-ID: <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <51B64AD8.6000402@bbiw.net> In-Reply-To: <51B64AD8.6000402@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 06uUu6cc9I97g9/72uVuFA== Content-Type: text/plain; charset="Windows-1252" Content-ID: <54DD43BAA766544787B466B65FE27445@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Stephen Farrell , "stir@ietf.org" Subject: Re: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 22:10:11 -0000 Inline On Jun 10, 2013, at 5:53 PM, Dave Crocker wrote: > On 6/10/2013 4:26 PM, Rosen, Brian wrote: >> 6. The originating and terminating end devices are SIP connected, and de= sire to authenticate the caller, but there are one or more hops (possibly i= ncluding the first or last hops) where the identity authentication mechanis= m is dropped. >=20 >=20 > Brian, >=20 > Thanks for circulating the cases. >=20 > (Purely OT: The form of Cases 4 and 5 was interesting, by way of suggest= ing that you've been spending far too much time around patents=85) Too true :) >=20 > I assume that simplistic diagrams of actors for these cases is something = like: >=20 >=20 > PSTN>SIP G/W -->+ +-> SIP>PSTN GW > | | > +-> SIP Op1..SIP OpN -+ > | | > Caller SIP UA ->+ +- Callee SIP UA That middle line today is often SIP Op1..Sip OpM ->SIP>PSTN GW -> SS7 -> PS= TN>SIP GW -> SIP Op M+1.. SIP OpN Most of the problem is SIP originated, PSTN terminated today, but that is c= hanging >=20 > (However I thought that SIP allows true peer-peer exchanges, too, without= mediation by an operator?) Yeah, but that roughly never happens with telephone number based identities >=20 > Using "signing" and "verifying" as generic terms here, who can do each? = If any SIP-related actor is prohibited, then why? In theory anyone with knowledge of the identity of the originator can sign.= In practice that means the endpoint, PBX or first SP. Anyone can validat= e. We would like to get to end to end validation, but we get a whole lot of va= lue over any entity in the path doing the validation. We would like to get= to a state where we have SPs refusing calls from downstream SPs who don't = have valid signatures.=20 >=20 > For example, I'd assume that a Callee SIP UA could do verification accord= ing to the architecture, even if that's not expected to be a typical operat= ional mode. If not, why not? Ideally, yes. There are discussions of how hard it is to get the informati= on that is signed through the SIP network end to end in order that the endp= oints can do the verification. A shortcut may be to use information only v= isible to SPs. I'd prefer not to do that, but it seems easier to some of t= he folks on the list. A really typical path is bad guy to "pink" carrier to "green carrier" to so= me arbitrary path that is not all SIP. If the "green" carrier verified, an= d didn't accept non valid calls from the pink SP, it would stop the proble= m. Sometimes there are a couple of SPs between pink and green (in both the= call path and color). Some of us really want the call to work if there is an SS7 hop in the middl= e, because that is where most calls are now. If the carrier on the origina= tion side of the SS7 hop verifies, great, but if all they do is pass along = the verification info, we'd like to be able to have some out-of-band way to= get it back. There are a couple of ideas on how to do that. There has b= een an argument that by the time we could get anything deployed, we will ha= ve eliminated that hop. I'm sanguine about that. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jun 10 15:55: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 B271421F96E4 for ; Mon, 10 Jun 2013 15:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 fsr8w3PL35kN for ; Mon, 10 Jun 2013 15:55:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3221F96C2 for ; Mon, 10 Jun 2013 15:55:18 -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 r5AMt298029957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jun 2013 22:55:03 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 r5AMt3oB013354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jun 2013 22:55:04 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5AMt2MR014973; Mon, 10 Jun 2013 22:55:02 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 15:55: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: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> Date: Mon, 10 Jun 2013 18:55:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1E2F00-C5A3-4304-A6FF-45C7B57EA23A@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Dave Crocker , "" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical phone numbers survive SBCs and other middle boxes?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 22:55:24 -0000 On Jun 10, 2013, at 4:47 PM, "Rosen, Brian" = wrote: > ENUM does not exist. > We have an RFC, but we have essentially no deployment. > ENUM, as originally envisioned, was a public database. That is a = complete non-starter. > ENUM tried to evolve to a private database, but in most places, it was = not possible to organize the relationships to make it work. Not to pick too much on the above comment, because it doesn't matter too = much in this conversation, but ISTM private use of ENUM is actually very = successful. =20 Hundreds of large service providers, including some of the largest = mobile providers on the planet, use it a LOT, with multiple vendor = implementations. It just doesn't exit each provider's network (ie, it's neither Public = nor Carrier ENUM).=20 -hadriel From brian.rosen@neustar.biz Mon Jun 10 16:47: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 8A36B21F99FE for ; Mon, 10 Jun 2013 16:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 zQCObGbwNafe for ; Mon, 10 Jun 2013 16:47:30 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB5421F99DB for ; Mon, 10 Jun 2013 16:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370908527; x=1686262144; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=KXz1XoFWwI 3m3qh8zAzWKkNvaEBWQcBrj240g5IYr+s=; b=nvob33EOp+uonl8SnNqXjmvS9Q CFwcbzuYAFLYtBLB0eRr2smcZ7R56xfgrAGd6Lam6rAsQ9PBQFwhi2iJ5I9w== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26060497; Mon, 10 Jun 2013 19:55:26 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Jun 2013 19:47:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 10 Jun 2013 19:47:14 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABKAAgAAYjACAABLAAIAAFJwAgAAOT4CAAAJxgIAAExkAgAAbzwA= Date: Mon, 10 Jun 2013 23:47:13 +0000 Message-ID: <41697C6C-A243-4A27-A06D-A5BDB825192F@neustar.biz> References: <2A247775-BE6B-433B-AD11-DF663DC6BAF0@neustar.biz> <018701ce6601$53a6e4d0$faf4ae70$@shockey.us> <8A46641C-7981-4CE1-846F-2F0F4FA7AE41@edvina.net> <51B63C1B.6040908@bbiw.net> <5D2DEEA6-9D29-416E-BE8C-BC95C1B03F60@neustar.biz> <51B64E2C.8000907@dcrocker.net> In-Reply-To: <51B64E2C.8000907@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hh+462/rdGS6oi0Jq8ibfQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <57569254AC72DC4EBE4F6E6950C63CCF@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 23:47:34 -0000 You explaining how telephone number based routing to me is like me trying t= o explain email routing to you :) Typically, the SP serving the mobile is different from the one serving the = office. The mobile does not have the office number as one of the numbers i= n its SIM. If the mobile has the office number in your SIM, then today, the service pr= oviders have to be the same in the office and the mobile, because today, ro= uting of telephone number based calls depends on a mapping of telephone num= ber to service provider. That is mechanized in different ways in different= countries often actually mapping from a telephone number to a switch owned= by the SP, but increasingly, it really is mapping TN to SP Id. If they did have the same SP, and the office number was in the SIM, then it= 's not spoofing at all, and the basic mechanisms we're discussing would all= work fine. The case we need extra mechanism for is when the mobile does n= ot have the office number on its SIM, and especially the case where the mob= ile SP and the office SP are not the same.=20 Brian On Jun 10, 2013, at 6:07 PM, Dave Crocker wrote: > On 6/10/2013 3:59 PM, Rosen, Brian wrote: >> If a service let's a doctor place a call from his mobile, that >> appears to come from his office, >=20 > That's a reasonable description of many people's views about a phone numb= er, but of course it's now quite wrong and has been for many years. This d= emonstrates the difference between "common" and "required". >=20 > Phone numbers no longer are required to refer to a device, a geographic l= ocation, a network topological location or a service operator. They've bec= ome a random string, whose meaning is established by use and entry into a d= atabase. (Let's skip over the oddness of my reciting this to someone at a = company that makes this fact workable.) >=20 > I made many 'local' phone calls last week, while I was in Austria. By lo= cal I mean even the phone company thought I was 'home' in California. They= provide a WiFi-based Internet path for calls to/from my mobile phone and t= herefore don't care at all where I am physically. (And my carrier charges = according to home access.) >=20 > The phone number refers to the SIM card, in this case. >=20 > Had I made a call from a phone with a different SIM card but caused calle= r ID to show my original number, that would be mechanically interesting, bu= t not at all interesting for the callee. They'd see my number and I'm the = one calling. >=20 >=20 >> I don't really care what we call it, but it is substituting the real >> identifier. The only difference between the service doing it and a >> scammer doing it is permission. >=20 > "real" identifier? >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dcrocker@bbiw.net Mon Jun 10 16:50: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 7F95121F96C6 for ; Mon, 10 Jun 2013 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=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 G-jhzGazVqDH for ; Mon, 10 Jun 2013 16:50:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76521F9050 for ; Mon, 10 Jun 2013 16:50:44 -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 r5ANob2b032535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 16:50:40 -0700 Message-ID: <51B6664A.6090603@bbiw.net> Date: Mon, 10 Jun 2013 18:50:34 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <51B64AD8.6000402@bbiw.net> <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> In-Reply-To: <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Mon, 10 Jun 2013 16:50:41 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 10 Jun 2013 23:50:52 -0000 On 6/10/2013 5:09 PM, Rosen, Brian wrote: >> I assume that simplistic diagrams of actors for these cases is something like: >> >> >> PSTN>SIP G/W -->+ +-> SIP>PSTN GW >> | | >> +-> SIP Op1..SIP OpN -+ >> | | >> Caller SIP UA ->+ +- Callee SIP UA > > That middle line today is often SIP Op1..Sip OpM ->SIP>PSTN GW -> SS7 -> PSTN>SIP GW -> SIP Op M+1.. SIP OpN > Most of the problem is SIP originated, PSTN terminated today, but that is changing Ahh. Right. So, a bit of a hack to represent, but to at least touch the additional issue: +---------------------------------------------+ | ^ V | SS7>SIP G/W -->+ +-> SIP>SS7 GW -+ | | | +-> SIP Op1...SIP OpN -+ +-> Callee | | | Caller SIP UA ->+ +-> SIP UA -----+ >> (However I thought that SIP allows true peer-peer exchanges, too, without mediation by an operator?) > Yeah, but that roughly never happens with telephone number based identities OK. That's what I assumed. >> Using "signing" and "verifying" as generic terms here, who can do each? If any SIP-related actor is prohibited, then why? > In theory anyone with knowledge of the identity of the originator can sign. In practice that means the endpoint, PBX or first SP. Anyone can validate. > We would like to get to end to end validation, but we get a whole lot of value over any entity in the path doing the validation. We would like to get to a state where we have SPs refusing calls from downstream SPs who don't have valid signatures. Glad to hear this. But of course it makes the trust model messier, since you don't begin with trusted actors (like operators) controlling things. And it means that there's potentially a key for each number. /And/ you want to allow signing by folk who don't 'own' the number. >> For example, I'd assume that a Callee SIP UA could do verification according to the architecture, even if that's not expected to be a typical operational mode. If not, why not? > Ideally, yes. There are discussions of how hard it is to get the information that is signed through the SIP network end to end in order that the endpoints can do the verification. A shortcut may be to use information only visible to SPs. I'd prefer not to do that, but it seems easier to some of the folks on the list. > > A really typical path is bad guy to "pink" carrier to "green carrier" to some arbitrary path that is not all SIP. If the "green" carrier verified, and didn't accept non valid calls from the pink SP, it would stop the problem. Sometimes there are a couple of SPs between pink and green (in both the call path and color). > > Some of us really want the call to work if there is an SS7 hop in the middle, because that is where most calls are now. If the carrier on the origination side of the SS7 hop verifies, great, but if all they do is pass along the verification info, we'd like to be able to have some out-of-band way to get it back. There are a couple of ideas on how to do that. There has been an argument that by the time we could get anything deployed, we will have eliminated that hop. I'm sanguine about that. FWIW, at a coarse, architectural level, what you are describing is quite similar to what DKIM confronts for email, including 'gatewaying' which in the email case is represented by mailing list processing -- which is formally a delivery to the list engine and a re-posting by it. (I did said 'coarse'.) For DKIM, the current view is that mailing lists need to re-sign the message; that would be an SS7>SIP gateway re-signing, here. But, of course, it won't have the private key of the owner of the number... Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than mailing lists, but from the traffic I've seen here, it doesn't sound reliable. At a minimum, you might want to specify the core stuff without specifying the SS7 relaying -- include it in the thinking but not the formal spec -- and specify ss7 gatewaying separately. That's more than a documentation nuance. It makes for a /far/ simpler spec, because the core model is kept quite simple. (I've always thought that, but watching the problems in the recent EAI wg with this solidified the point for me.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From york@isoc.org Mon Jun 10 17:16: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 70D4E21F9412 for ; Mon, 10 Jun 2013 17:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.766 X-Spam-Level: X-Spam-Status: No, score=-104.766 tagged_above=-999 required=5 tests=[AWL=1.833, 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 Iri68oQqYp+8 for ; Mon, 10 Jun 2013 17:16:46 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50021F934B for ; Mon, 10 Jun 2013 17:16:46 -0700 (PDT) Received: from mail4-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Jun 2013 00:16:46 +0000 Received: from mail4-co9 (localhost [127.0.0.1]) by mail4-co9-R.bigfish.com (Postfix) with ESMTP id 0E755140147; Tue, 11 Jun 2013 00:16:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zz1519Mzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail4-co9 (localhost.localdomain [127.0.0.1]) by mail4-co9 (MessageSwitch) id 1370909804486490_19696; Tue, 11 Jun 2013 00:16:44 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.243]) by mail4-co9.bigfish.com (Postfix) with ESMTP id 738D680198; Tue, 11 Jun 2013 00:16:44 +0000 (UTC) Received: from BL2PRD0610HT004.namprd06.prod.outlook.com (157.56.240.117) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Jun 2013 00:16:44 +0000 Received: from BL2PRD0610MB374.namprd06.prod.outlook.com ([169.254.5.235]) by BL2PRD0610HT004.namprd06.prod.outlook.com ([10.255.101.39]) with mapi id 14.16.0311.000; Tue, 11 Jun 2013 00:16:41 +0000 From: Dan York To: "Rosen, Brian" , "dcrocker@bbiw.net" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZhxTdDF03iKwj0e3WIPP666+Y5kvboeAgAATGQCAABvQgP//xS2A Date: Tue, 11 Jun 2013 00:16:41 +0000 Message-ID: In-Reply-To: <41697C6C-A243-4A27-A06D-A5BDB825192F@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 00:16:52 -0000 >If they did have the same SP, and the office number was in the SIM, then >it's not spoofing at all, and the basic mechanisms we're discussing would >all work fine. The case we need extra mechanism for is when the mobile >does not have the office number on its SIM, and especially the case where >the mobile SP and the office SP are not the same. And let's please keep in mind that the doctor calling the patient might not necessarily be using a mobile phone and therefore would not have access to a SIM. They might be using a wired phone at their home - or they might be using a softphone on a laptop or mobile device connected in to some VoIP system. I'd note that today they might not have the option of presenting an alternate number - they might opt instead to simply block their number from appearing (what a doctor friend of mine does, which has the amusing side effect that I pretty much always know it is her when she calls). Dan From dcrocker@bbiw.net Mon Jun 10 17:33: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 445D921E809B for ; Mon, 10 Jun 2013 17:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 J2uRCsy4LRc3 for ; Mon, 10 Jun 2013 17:33:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B86521E809C for ; Mon, 10 Jun 2013 17:33:16 -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 r5B0XCBn000572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 17:33:16 -0700 Message-ID: <51B67045.2060607@bbiw.net> Date: Mon, 10 Jun 2013 19:33:09 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dan York 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.67]); Mon, 10 Jun 2013 17:33:16 -0700 (PDT) Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 00:33:22 -0000 On 6/10/2013 7:16 PM, Dan York wrote: > I'd note that today they might not have the option of presenting an > alternate number - That raises another point probably worth making explicit: To what extent is the goal essentially to emulate existing PSTN functionality and to what extent is it providing a new capability. Since caller id is faked today in the PSTN, I assume the intent here is something /better/ than exists in the current phone service. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard@shockey.us Mon Jun 10 17:35: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 CF72021E809B for ; Mon, 10 Jun 2013 17:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=0.153, 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 iOzyNLMkAOj3 for ; Mon, 10 Jun 2013 17:35:20 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 61DD121E8098 for ; Mon, 10 Jun 2013 17:35:20 -0700 (PDT) Received: (qmail 27186 invoked by uid 0); 11 Jun 2013 00:35:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 11 Jun 2013 00:35:19 -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=CLUynTle1A9uJHxd7bmQDDBori4fye388EuY0ybETZk=; b=DFGs5zPztuo+c5IKa40E0MWhkMml+9Cs4t8uv3/EXdfv8AgZyfgIO94zCeqZ9E7bHofg6JYhwhXnj4yJxjEZCbVtU0itxPEwe7YNO0d3QZZVwO+ElppZl5pjXIzSL+0p; Received: from [72.66.111.124] (port=58282 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UmCYQ-0005Ek-GT; Mon, 10 Jun 2013 18:35:18 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , "'Stephen Farrell'" , "'Henning Schulzrinne'" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> In-Reply-To: <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> Date: Mon, 10 Jun 2013 20:35:13 -0400 Message-ID: <00ec01ce663b$8ab367c0$a01a3740$@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: AQKmG5pz++37aVJTb/vHdV/W8NbSYwHntOc5AjPy0gQBwyf+LAIYhVyTAaq0kXEB3hSFgAGpeArgAiMa3MQBND7N1Jb8MM0A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Dave Crocker' , dcrocker@bbiw.net Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical phone numbers survive SBCs and other middle boxes?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 00:35:24 -0000 Ah excuse me .. Why oh why does this come back to haunt me .. Like the Godfather III movie .. " once you think you are out, they pull you back in." -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, June 10, 2013 4:47 PM To: Stephen Farrell Cc: stir@ietf.org; Dave Crocker; Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical phone numbers survive SBCs and other middle boxes?) ENUM does not exist. [RS> ] [RS> ] It bloody well does exist.. not as e164.arpa but as private instantiations all over the place as well as a access protocol to Centralized Routing Databases internal to service provider networks. The IP SCP. SIP Redirect is currently preferred but the protocols are still built into the CSCF's. TCAP replacement.. duh let me know I can make up T-Shirts for Berlin .NO TCAP. NeuStar runs the I-TRS database for the hearing impaired for the FCC which is entirely based on 6116. Brian .don't go there. Yes your company runs a government sponsored private instantiation of 6116. Look it up people. We have an RFC, but we have essentially no deployment. ENUM, as originally envisioned, was a public database. That is a complete non-starter. [RS> ] [RS> ] In .arpa sure but the protocol is still in very active use. The ENUM WG declared success and I'm personally proud of that. Well now that you kindly bring up the subject. What if .. what if you did actually looked at reviving .e164.arpa but only as a tree for PKI and NO session establishment data? Well Hummmm maybe there is merit to that idea. The structural separation of PKI data from the underlying national numbering databases could offer some interesting alternatives. Worth thinking about. Worth discussing .. Granted I have some serious scars from the E2MD BOF's in 2010 but .. Well it might be worth a trial .. WOW. Gee I think I need to make a filing with the FCC as part of their DA 13-1016 filing. http://www.fcc.gov/document/technology-transitions-policy-task-force-seeks-c omment-trials Great Idea Brian thanks for the suggestion. What a guy!!! You are the best! ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work. What works is number delegation, and centralized databases like the US NPAC. The proposed basic mechanism doesn't depend on a database of certs. The URL to the cert accompanies the signature. One of the proposed mechanisms for handling the so-called "out of band" mechanism that gets around SS7 links and SPs that don't preserve the signed information does depend on such a database. I think that is a weakness. There are ways to create such a database which do not depend on DNS. Brian On Jun 10, 2013, at 4:21 PM, Stephen Farrell wrote: > > Hi > > On 06/07/2013 08:17 PM, Dave Crocker wrote: >> (Just to be clear, I'm suggesting consideration of an approach; I'm >> not sure it's the best one and I'm therefore not pushing for its >> adoption, merely that it be explored.) >> >> Anyone can sign. They sign with a domain they own. So the signature >> goes with the operator, not with the content (number, message, >> whatever.) > > I'd also like to understand the argument here as to whether a DKIM > like approach to public key retrieval is good enough or not for this > application. (Note that this is orthogonal to any discussion about a > DKIM-like or 4474-like signature format, I'm just asking about public > key retrieval now.) > > As with everything, I don't need to understand it now, but I do think > that a bunch of folks here are making assumptions about PKI that might > turn out to be a large amount of work later, e.g. that TN delegation > specific certificate chains exist, can be found and can be verified > efficiently. > > One could easily argue that since ENUM exists and DKIM key records > exist (*) a DNS lookup could be the way to get signers' public keys > without requiring any 5280 processing at all at the signer or verifier. > > One could further argue that that'd be sufficiently "secure" even > without DNSSEC, in that it'd be enough to mitigate your robocaller > issues on the basis that those robocallers aren't gonna MITM or poison > DNS at the verifier. > > A similar argument was made for DKIM: since a bad DKIM signature is > the same as no signature on a mail message, there's no need to require > DNSSEC to get DKIM started. > > While its not quite the same in this context, it may be that one could > argue that a reasonable threat model would not require the signature > verifier (someone/thing en-route to the callee) to strongly verify the > signing public key. > > (Ok, I can't resist adding a feature:-) If the DKIM key selector were > modified (to put it in the key value) then you might also get some > level of traceability in that one could trawl the DNS for signer's > public keys. I don't know if that'd be good or bad. > > Anyway, for now, can we make sure this gets discussed before we plump > for any specific key management solution? That could be now, or at a > DISPATCH session or BoF or after a WG is chartered, I don't mind, so > long as it is properly considered. > > S. > > (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. > For the present discussion, just assume that the keys are in the > "correct" kind of RR. > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Mon Jun 10 17:53: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 0AB8721F992E for ; Mon, 10 Jun 2013 17:53:28 -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 6rk-uYxaqNSh for ; Mon, 10 Jun 2013 17:53:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9006E21F98AD for ; Mon, 10 Jun 2013 17:53:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E96E5BE7B for ; Tue, 11 Jun 2013 01:53:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB8cNhlqdEVV for ; Tue, 11 Jun 2013 01:52:54 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.23.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88583BE7C for ; Tue, 11 Jun 2013 01:52:54 +0100 (IST) Message-ID: <51B674DB.9060809@cs.tcd.ie> Date: Tue, 11 Jun 2013 01:52:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <00ec01ce663b$8ab367c0$a01a3740$@shockey.us> In-Reply-To: <00ec01ce663b$8ab367c0$a01a3740$@shockey.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [stir] clarity (was: Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 00:53:28 -0000 FWIW - I have no idea how to interpret Rich's message and as a result am also unsure how to interpret Brian's. And that's about the 5th or 6th overly cryptic mail like that in the last few days from various folks on this list. So this isn't really aimed at either Brian or Rich but is a general plea for clarity. I'm sure there are a bunch of people on here who have all the context for all this. But I'm not one of 'em. And I bet I'm not alone. Assuming a homogeneous audience who all share the same painful history is yet another way to bugger up a BoF in my experience. Just sayin. S. On 06/11/2013 01:35 AM, Richard Shockey wrote: > Ah excuse me .. Why oh why does this come back to haunt me .. > > Like the Godfather III movie .. " once you think you are out, they pull you > back in." > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: Monday, June 10, 2013 4:47 PM > To: Stephen Farrell > Cc: stir@ietf.org; Dave Crocker; > Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical > phone numbers survive SBCs and other middle boxes?) > > ENUM does not exist. > [RS> ] > [RS> ] It bloody well does exist.. not as e164.arpa but as private > instantiations all over the place as well as a access protocol to > Centralized Routing Databases internal to service provider networks. The IP > SCP. SIP Redirect is currently preferred but the protocols are still built > into the CSCF's. TCAP replacement.. duh let me know I can make up T-Shirts > for Berlin .NO TCAP. NeuStar runs the I-TRS database for the hearing > impaired for the FCC which is entirely based on 6116. Brian .don't go > there. Yes your company runs a government sponsored private instantiation > of 6116. Look it up people. > > We have an RFC, but we have essentially no deployment. > > ENUM, as originally envisioned, was a public database. That is a complete > non-starter. > [RS> ] > [RS> ] In .arpa sure but the protocol is still in very active use. The ENUM > WG declared success and I'm personally proud of that. Well now that you > kindly bring up the subject. What if .. what if you did actually looked at > reviving .e164.arpa but only as a tree for PKI and NO session establishment > data? Well Hummmm maybe there is merit to that idea. The structural > separation of PKI data from the underlying national numbering databases > could offer some interesting alternatives. Worth thinking about. Worth > discussing .. > > Granted I have some serious scars from the E2MD BOF's in 2010 but .. > > Well it might be worth a trial .. WOW. Gee I think I need to make a filing > with the FCC as part of their DA 13-1016 filing. > > http://www.fcc.gov/document/technology-transitions-policy-task-force-seeks-c > omment-trials > > Great Idea Brian thanks for the suggestion. What a guy!!! You are the > best! > > > > ENUM tried to evolve to a private database, but in most places, it was not > possible to organize the relationships to make it work. > > What works is number delegation, and centralized databases like the US NPAC. > > The proposed basic mechanism doesn't depend on a database of certs. The URL > to the cert accompanies the signature. > > One of the proposed mechanisms for handling the so-called "out of band" > mechanism that gets around SS7 links and SPs that don't preserve the signed > information does depend on such a database. I think that is a weakness. > There are ways to create such a database which do not depend on DNS. > > Brian > On Jun 10, 2013, at 4:21 PM, Stephen Farrell > wrote: > >> >> Hi >> >> On 06/07/2013 08:17 PM, Dave Crocker wrote: >>> (Just to be clear, I'm suggesting consideration of an approach; I'm >>> not sure it's the best one and I'm therefore not pushing for its >>> adoption, merely that it be explored.) >>> >>> Anyone can sign. They sign with a domain they own. So the signature >>> goes with the operator, not with the content (number, message, >>> whatever.) >> >> I'd also like to understand the argument here as to whether a DKIM >> like approach to public key retrieval is good enough or not for this >> application. (Note that this is orthogonal to any discussion about a >> DKIM-like or 4474-like signature format, I'm just asking about public >> key retrieval now.) >> >> As with everything, I don't need to understand it now, but I do think >> that a bunch of folks here are making assumptions about PKI that might >> turn out to be a large amount of work later, e.g. that TN delegation >> specific certificate chains exist, can be found and can be verified >> efficiently. >> >> One could easily argue that since ENUM exists and DKIM key records >> exist (*) a DNS lookup could be the way to get signers' public keys >> without requiring any 5280 processing at all at the signer or verifier. >> >> One could further argue that that'd be sufficiently "secure" even >> without DNSSEC, in that it'd be enough to mitigate your robocaller >> issues on the basis that those robocallers aren't gonna MITM or poison >> DNS at the verifier. >> >> A similar argument was made for DKIM: since a bad DKIM signature is >> the same as no signature on a mail message, there's no need to require >> DNSSEC to get DKIM started. >> >> While its not quite the same in this context, it may be that one could >> argue that a reasonable threat model would not require the signature >> verifier (someone/thing en-route to the callee) to strongly verify the >> signing public key. >> >> (Ok, I can't resist adding a feature:-) If the DKIM key selector were >> modified (to put it in the key value) then you might also get some >> level of traceability in that one could trawl the DNS for signer's >> public keys. I don't know if that'd be good or bad. >> >> Anyway, for now, can we make sure this gets discussed before we plump >> for any specific key management solution? That could be now, or at a >> DISPATCH session or BoF or after a WG is chartered, I don't mind, so >> long as it is properly considered. >> >> S. >> >> (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. >> For the present discussion, just assume that the keys are in the >> "correct" kind of RR. >> > > _______________________________________________ > 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 Mon Jun 10 18:08: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 CB2591F0D24 for ; Mon, 10 Jun 2013 18:08:28 -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 pVfC0WyeP3Am for ; Mon, 10 Jun 2013 18:08:24 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 239F51F0CE7 for ; Mon, 10 Jun 2013 18:08:24 -0700 (PDT) Received: (qmail 32381 invoked by uid 0); 11 Jun 2013 01:08:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 11 Jun 2013 01:08: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=i7FVBAudItR+lSW9UGT5k5m1+N02ULV9MBYfgSOsAYU=; b=H6A4CBtBZj9cFR/unskrOhF799mVZtZ8ztTpdZQbXNl1wsULg84/3Xm0dgKURKq2UGj9NHYWdAk0ZFimQtYXHPvI2CwvrhZ6OKGCtJex5UmL2i5r6r8Y+44OZKeF+/Bm; Received: from [72.66.111.124] (port=58532 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UmD44-0004DE-0N; Mon, 10 Jun 2013 19:08:00 -0600 From: "Richard Shockey" To: "'Dave Crocker'" , "'Dan York'" References: <51B67045.2060607@bbiw.net> In-Reply-To: <51B67045.2060607@bbiw.net> Date: Mon, 10 Jun 2013 21:07:55 -0400 Message-ID: <00f401ce6640$1bd77c10$53867430$@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: AQNGB/cpvfIadzjj+eENiOSvwhtQ3gMiki4plidXjVA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: "'Rosen, Brian'" , stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 01:08:29 -0000 Dave both.. we have to preserve protect and defend the existing structure until the time comes for a real Transition and that time is now. In short we .. The IETF won. There are no "flash cuts" here we have to Transition. The US and the NANP are going to have to deal with this first since the level of SIP in the US and Canada network is pretty amazing. We, the IETF, are now the actual stewards of the Public SIP Telephony network. PSTN by another name. We want E.164 identifiers to link to advanced classes of services for all of all types including P2P video etc and an all the things Unified Communications promised for the last decade including a host of real M2M applications as well. This is not a national specific task. Though there are endless issues the IETF is not competent to address such as ICC/USF EC based roaming charges and endless national specific issues. We do tools. This work is part of that. E.164 identifiers are a great tool for lots of things no one has though of .. this work is useful. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Monday, June 10, 2013 8:33 PM To: Dan York Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? On 6/10/2013 7:16 PM, Dan York wrote: > I'd note that today they might not have the option of presenting an > alternate number - That raises another point probably worth making explicit: To what extent is the goal essentially to emulate existing PSTN functionality and to what extent is it providing a new capability. Since caller id is faked today in the PSTN, I assume the intent here is something /better/ than exists in the current phone service. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From york@isoc.org Mon Jun 10 18:52: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 60CA021E8094 for ; Mon, 10 Jun 2013 18:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.724 X-Spam-Level: X-Spam-Status: No, score=-103.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 AALRBOcYCccw for ; Mon, 10 Jun 2013 18:52:13 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9893621E804E for ; Mon, 10 Jun 2013 18:52:13 -0700 (PDT) Received: from mail78-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Jun 2013 01:52:12 +0000 Received: from mail78-co1 (localhost [127.0.0.1]) by mail78-co1-R.bigfish.com (Postfix) with ESMTP id A529BD003EE; Tue, 11 Jun 2013 01:52:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT001.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275chz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; LANG:en; Received: from mail78-co1 (localhost.localdomain [127.0.0.1]) by mail78-co1 (MessageSwitch) id 1370915530316928_7604; Tue, 11 Jun 2013 01:52:10 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.249]) by mail78-co1.bigfish.com (Postfix) with ESMTP id 4127AD4004E; Tue, 11 Jun 2013 01:52:10 +0000 (UTC) Received: from BL2PRD0610HT001.namprd06.prod.outlook.com (157.56.240.117) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Jun 2013 01:52:10 +0000 Received: from BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) by BL2PRD0610HT001.namprd06.prod.outlook.com (10.255.101.36) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 11 Jun 2013 01:52:08 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 11 Jun 2013 01:51:45 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.130]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.15]) with mapi id 15.00.0702.005; Tue, 11 Jun 2013 01:51:45 +0000 From: Dan York To: Dave Crocker Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZhxTdDF03iKwj0e3WIPP666+Y5kvboeAgAATGQCAABvQgP//xS2AgABHqID//9LhgA== Date: Tue, 11 Jun 2013 01:51:45 +0000 Message-ID: In-Reply-To: <51B67045.2060607@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <323273D949C76E4AB57368E1CBEDCE1D@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 01:52:24 -0000 Dave, On 6/10/13 8:33 PM, "Dave Crocker" wrote: >On 6/10/2013 7:16 PM, Dan York wrote: >> I'd note that today they might not have the option of presenting an >> alternate number - > > >That raises another point probably worth making explicit: To what >extent is the goal essentially to emulate existing PSTN functionality >and to what extent is it providing a new capability. > >Since caller id is faked today in the PSTN, I assume the intent here is >something /better/ than exists in the current phone service. Yes, the overall goal is to get to "caller ID" that is secure and can't be faked. That is something *better* than what we have today. Now, separately, my note was about the doctor wanting to make a call from his/her mobile and present a number from his/her office. This may be a desired behavior but also may or may not be something that is commonly available today - largely depending upon the doctor's setup and how he/she is integrated with it. There certainly *are* today contact centers that legitimately present themselves as having the phone number of the organization/company/enterprise for whom they are contracted. And there are application servers that legitimately present themselves as calling from the number of the org/company/enterprise. Both of those are very common cases where an entity is either making or receiving calls on behalf of some other entity and is presenting the identification of the other entity. That is again *existing* functionality that we want to ensure continues to work in a new setup. Dan From dcrocker@bbiw.net Mon Jun 10 20:07: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 8072511E80D5 for ; Mon, 10 Jun 2013 20:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 2n6EJMo4T-LA for ; Mon, 10 Jun 2013 20:07:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9045A11E80CC for ; Mon, 10 Jun 2013 20:07:43 -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 r5B37c5M003152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 20:07:42 -0700 Message-ID: <51B69477.6080106@bbiw.net> Date: Mon, 10 Jun 2013 22:07:35 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dan York 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.67]); Mon, 10 Jun 2013 20:07:42 -0700 (PDT) Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 03:07:48 -0000 On 6/10/2013 8:51 PM, Dan York wrote: > That is again*existing* functionality that we want to ensure continues to > work in a new setup. To be pedantic about this, for the record: The goal is to preserve existing flexibility in assigning the caller id, but to add a mechanism -- not present in the current PSTN -- that permits handling agents to validate the use of the id. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Mon Jun 10 21:31: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 6EB5911E80E1 for ; Mon, 10 Jun 2013 21:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, 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 JQkCGGe6S+rm for ; Mon, 10 Jun 2013 21:31:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 872B711E80DE for ; Mon, 10 Jun 2013 21:31:48 -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 r5B4VahA003256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 04:31:36 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 r5B4VZt8019727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 04:31:35 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 r5B4VZSw019722; Tue, 11 Jun 2013 04:31:35 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-151-53.vpn.oracle.com (/10.154.151.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jun 2013 21:31:35 -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: <51B674DB.9060809@cs.tcd.ie> Date: Tue, 11 Jun 2013 00:31:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA39C97-857B-4A1A-8265-E8E31A62DE1E@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <00ec01ce663b$8ab367c0$a01a3740$@shockey.us> <51B674DB.9060809@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: stir@ietf.org Subject: Re: [stir] clarity (was: Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 04:31:53 -0000 Well, it's a sensitive topic because in some ways and for some of us = ENUM was a miserable failure, and for others a wild success. I don't = know how much context/background you need though. I mean I don't know = how much you don't already know, or what is useful to know. Some background on the current state of ENUM as I see it: As originally described/envisioned ENUM was just a usage of DNS, as you = know... which from the IETF's perspective means 'The DNS', and thus not = only the protocol but also the architecture and massive DNS deployment, = query-able by any host on the Internet, etc. This is what most people = call "Public ENUM". It was a miserable failure. However, as DNS the *protocol* for querying numbers and getting back = URIs and other stuff for various purposes, ENUM is very successful. = It's just that the "DNS" servers being queried for ENUM purposes are not = in any way tied into 'The DNS', but are simply servers owned by the same = service provider that owns the equipment performing the queries, and are = not publicly reachable. That's 'Private ENUM'. It's only within = Service Providers, not in Enterprises... think of it as the Service = Provider's version of LDAP. There is also 'Carrier ENUM' which is pseudo-private, in the sense that = the servers are still not part of The DNS and are only query-able from = certain providers based on a federation or some form of common = agreement/relationship. Carrier ENUM exists, but is not very successful = afaik. Some background on using ENUM for Caller-ID verification: The topic has come up before, although I don't know if Rich or Brian = remember it. It was discussed about 5 years ago, back when we had = massive email threads about the many SIP Identity problems/solutions on = the mailing lists. There were even some drafts about it... This one discussed the general problem area: http://tools.ietf.org/html/draft-schwartz-sip-e164-ownership-01 And this one discussed using ENUM/DNS for a PKI: http://tools.ietf.org/html/draft-darilion-sip-e164-enum-00 -hadriel On Jun 10, 2013, at 8:52 PM, Stephen Farrell = wrote: >=20 > FWIW - I have no idea how to interpret Rich's message > and as a result am also unsure how to interpret Brian's. > And that's about the 5th or 6th overly cryptic mail like > that in the last few days from various folks on this > list. So this isn't really aimed at either Brian or > Rich but is a general plea for clarity. >=20 > I'm sure there are a bunch of people on here who have > all the context for all this. But I'm not one of 'em. > And I bet I'm not alone. >=20 > Assuming a homogeneous audience who all share the same > painful history is yet another way to bugger up a BoF in > my experience. Just sayin. >=20 > S. >=20 > On 06/11/2013 01:35 AM, Richard Shockey wrote: >> Ah excuse me .. Why oh why does this come back to haunt me .. >>=20 >> Like the Godfather III movie .. " once you think you are out, they = pull you >> back in."=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of >> Rosen, Brian >> Sent: Monday, June 10, 2013 4:47 PM >> To: Stephen Farrell >> Cc: stir@ietf.org; Dave Crocker; >> Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can = canonical >> phone numbers survive SBCs and other middle boxes?) >>=20 >> ENUM does not exist. >> [RS> ]=20 >> [RS> ] It bloody well does exist.. not as e164.arpa but as private >> instantiations all over the place as well as a access protocol to >> Centralized Routing Databases internal to service provider networks. = The IP >> SCP. SIP Redirect is currently preferred but the protocols are = still built >> into the CSCF's. TCAP replacement.. duh let me know I can make up = T-Shirts >> for Berlin .NO TCAP. NeuStar runs the I-TRS database for the = hearing >> impaired for the FCC which is entirely based on 6116. Brian .don't = go >> there. Yes your company runs a government sponsored private = instantiation >> of 6116. Look it up people.=20 >>=20 >> We have an RFC, but we have essentially no deployment. >>=20 >> ENUM, as originally envisioned, was a public database. That is a = complete >> non-starter. >> [RS> ]=20 >> [RS> ] In .arpa sure but the protocol is still in very active use. = The ENUM >> WG declared success and I'm personally proud of that. Well now that = you >> kindly bring up the subject. What if .. what if you did actually = looked at >> reviving .e164.arpa but only as a tree for PKI and NO session = establishment >> data? Well Hummmm maybe there is merit to that idea. The structural >> separation of PKI data from the underlying national numbering = databases >> could offer some interesting alternatives. Worth thinking about. = Worth >> discussing ..=20 >>=20 >> Granted I have some serious scars from the E2MD BOF's in 2010 but .. >>=20 >> Well it might be worth a trial .. WOW. Gee I think I need to make a = filing >> with the FCC as part of their DA 13-1016 filing. =20 >>=20 >> = http://www.fcc.gov/document/technology-transitions-policy-task-force-seeks= -c >> omment-trials >>=20 >> Great Idea Brian thanks for the suggestion. What a guy!!! You are = the >> best!=20 >>=20 >>=20 >>=20 >> ENUM tried to evolve to a private database, but in most places, it = was not >> possible to organize the relationships to make it work. >>=20 >> What works is number delegation, and centralized databases like the = US NPAC. >>=20 >> The proposed basic mechanism doesn't depend on a database of certs. = The URL >> to the cert accompanies the signature. >>=20 >> One of the proposed mechanisms for handling the so-called "out of = band" >> mechanism that gets around SS7 links and SPs that don't preserve the = signed >> information does depend on such a database. I think that is a = weakness. >> There are ways to create such a database which do not depend on DNS. >>=20 >> Brian >> On Jun 10, 2013, at 4:21 PM, Stephen Farrell = >> wrote: >>=20 >>>=20 >>> Hi >>>=20 >>> On 06/07/2013 08:17 PM, Dave Crocker wrote: >>>> (Just to be clear, I'm suggesting consideration of an approach; I'm=20= >>>> not sure it's the best one and I'm therefore not pushing for its=20 >>>> adoption, merely that it be explored.) >>>>=20 >>>> Anyone can sign. They sign with a domain they own. So the = signature=20 >>>> goes with the operator, not with the content (number, message,=20 >>>> whatever.) >>>=20 >>> I'd also like to understand the argument here as to whether a DKIM=20= >>> like approach to public key retrieval is good enough or not for this=20= >>> application. (Note that this is orthogonal to any discussion about a=20= >>> DKIM-like or 4474-like signature format, I'm just asking about = public=20 >>> key retrieval now.) >>>=20 >>> As with everything, I don't need to understand it now, but I do = think=20 >>> that a bunch of folks here are making assumptions about PKI that = might=20 >>> turn out to be a large amount of work later, e.g. that TN delegation=20= >>> specific certificate chains exist, can be found and can be verified=20= >>> efficiently. >>>=20 >>> One could easily argue that since ENUM exists and DKIM key records=20= >>> exist (*) a DNS lookup could be the way to get signers' public keys=20= >>> without requiring any 5280 processing at all at the signer or = verifier. >>>=20 >>> One could further argue that that'd be sufficiently "secure" even=20 >>> without DNSSEC, in that it'd be enough to mitigate your robocaller=20= >>> issues on the basis that those robocallers aren't gonna MITM or = poison=20 >>> DNS at the verifier. >>>=20 >>> A similar argument was made for DKIM: since a bad DKIM signature is=20= >>> the same as no signature on a mail message, there's no need to = require=20 >>> DNSSEC to get DKIM started. >>>=20 >>> While its not quite the same in this context, it may be that one = could=20 >>> argue that a reasonable threat model would not require the signature=20= >>> verifier (someone/thing en-route to the callee) to strongly verify = the=20 >>> signing public key. >>>=20 >>> (Ok, I can't resist adding a feature:-) If the DKIM key selector = were=20 >>> modified (to put it in the key value) then you might also get some=20= >>> level of traceability in that one could trawl the DNS for signer's=20= >>> public keys. I don't know if that'd be good or bad. >>>=20 >>> Anyway, for now, can we make sure this gets discussed before we = plump=20 >>> for any specific key management solution? That could be now, or at a=20= >>> DISPATCH session or BoF or after a WG is chartered, I don't mind, so=20= >>> long as it is properly considered. >>>=20 >>> S. >>>=20 >>> (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. >>> For the present discussion, just assume that the keys are in the=20 >>> "correct" kind of RR. >>>=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 >>=20 >>=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From oej@edvina.net Mon Jun 10 22:49: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 7DC8921F9A9B for ; Mon, 10 Jun 2013 22:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 s7mD5mA+avep for ; Mon, 10 Jun 2013 22:49:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7821F9A98 for ; Mon, 10 Jun 2013 22:49:40 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1004] (unknown [IPv6:2001:16d8:cc57:1000::42:1004]) by smtp7.webway.se (Postfix) with ESMTPA id 8D8D293C1AF; Tue, 11 Jun 2013 05:49:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 11 Jun 2013 07:49:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> References: To: Brian Rosen , "stir@ietf.org" X-Mailer: Apple Mail (2.1503) Cc: "Olle E. Johansson" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 05:49:47 -0000 10 jun 2013 kl. 20:58 skrev "Rosen, Brian" : > To stop the problem, I think we need to at least start with verification > across SP boundaries and the termination. We want to get to the point > where an SP doesn't accept calls from a downstream SP that isn't > verifiable. Long term, that might be more of an audit between SPs, rather > than a 100% check, and I think we would see 100% verification at the end > of the call (ideally the end device, but perhaps the termination SP). Great. Have we defined "service provider" ? I see call centers suddenly starting to sell SIP trunks. /O From michael.hammer@yaanatech.com Mon Jun 10 23:13: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 AFD1B21F9A73 for ; Mon, 10 Jun 2013 23:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PluPi1mZA1La for ; Mon, 10 Jun 2013 23:12:55 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 93BDB21F8EB3 for ; Mon, 10 Jun 2013 23:12:55 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 10 Jun 2013 23:12:54 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81k0Rag7WUmkWt6dxCH9sPJpkslruA//+M/0CAAH9IAIADajdg Date: Tue, 11 Jun 2013 06:12:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.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.132] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CE6683.D42D2380" MIME-Version: 1.0 Cc: "Brian.Rosen@neustar.biz" , "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 06:13:00 -0000 ------=_NextPart_000_0000_01CE6683.D42D2380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you stop it at the start, wouldn't that solve some fraction of the problem? Do we know how many calls are spoofed from the start versus from redirections? Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Saturday, June 08, 2013 10:03 PM To: Michael Hammer Cc: hgs@cs.columbia.edu; Brian.Rosen@neustar.biz; stir@ietf.org Subject: Re: [stir] Permitted spoofing I think the hope was to proactively prevent a bogus call from succeeding, as opposed to reactively hunting down the perpetrators after it happened. The latter case should be possible now, since CDRs record enough to backtrack to the upstream provider, and that provider's CDRs can find its upstream provider, etc. -hadriel On Jun 8, 2013, at 2:30 PM, Michael Hammer wrote: > Question: Do we really care how many redirections occurred in the > middle network hops if we know what the original source of the signaling was? > > Put another way, if we have a legitimate scape-goat for a problem > call, do you need to catch all the stooges all at once? > > Mike > ------=_NextPart_000_0000_01CE6683.D42D2380 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx MTA2MTI0MlowIwYJKoZIhvcNAQkEMRYEFPUMhqsYfJa4ngyqMMdFpL8lTmriMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEASrjLEczxtNi0Pu6F2xBaiUpiACTC3qC1CS5uoXTd +mzGMsR8sBAvKtzyydCM/u2SAB3oMOhli7HJXnxC7/tydNbQolD4sfySwDhgbdMRGRDKqtmlN5jX i1EQzAXkmUaH6IZWZbrvALoiPTDl7ybJDWfurWIJbAGX6ZT6VhbgNuzzNX36Yuh9XwPg1G+0GbPR vQjEFZLGC750VI5QTL6CKojPg8LlJCfFcoJfsX00G6by/kfDkOw4fZ70F+tx+LsyK5uL74bt9ZVU R5LrXCS4LxQ/HUZV1vpKYdBENP/eJFmvmIOWY+TfDiCLffZLSJhyjgTXLfb+X9UaZyrnEkLZ7wAA AAAAAA== ------=_NextPart_000_0000_01CE6683.D42D2380-- From michael.hammer@yaanatech.com Mon Jun 10 23:42: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 8656B21F96EA for ; Mon, 10 Jun 2013 23:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fK3fiUMZbAqm for ; Mon, 10 Jun 2013 23:42: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 814C721F96C2 for ; Mon, 10 Jun 2013 23:42:54 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 10 Jun 2013 23:42:52 -0700 From: Michael Hammer To: "Brian.Rosen@neustar.biz" , "dcrocker@bbiw.net" Thread-Topic: DKIM-like key mgmt approach Thread-Index: AQHOZiEuR/SilMBAYkCxH8IXYk3wSJkwEQTw Date: Tue, 11 Jun 2013 06:42:51 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> In-Reply-To: <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.132] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0027_01CE6688.08402510" MIME-Version: 1.0 Cc: "stir@ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 06:42:58 -0000 ------=_NextPart_000_0027_01CE6688.08402510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All these use cases suggest that the original caller is the perp. Do you have a use case where the original caller is not the perp? Part of my issue is the complexity being introduced on the network components that would likely bog everything down. Hence, my trying to focus on where the perp likely is. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, June 11, 2013 12:26 AM To: Cc: stir@ietf.org; Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach Fair criticism, although use cases wouldn't help understanding why ENUM is not likely to work as part of the solution. Here is a start 1. A robocaller on a SIP network places calls to unwitting victims where they intentionally obscure, drop or spoof the calling party number. There is a SIP connection from end to end, although there are very often several service providers in the path. The SP to which the robocaller is directly connected permits this use, perhaps by turning a blind eye to it rather than expressly countenancing it. Assume that the service provider at the end of the call would be willing to check validity of the calling party identity. 2. A perpetrator places a call to a victim using the (spoofed) telephone number of the bank. CallerId appears to be the bank. The fisher claims the victim is the subject of an identity theft and the caller will help, but they need some verification information from the victim. "If you could just confirm your social security number and date of birth please.". Also SIP end to end. 3. A kid with a script fakes a call to the emergency number (1-1-2, 9-1-1, .) with a spoofed From and claims they see many armed intruders in a neighbors house. Call out the SWAT team. Also SIP end to end. 4. The above 3 cases where the called party is not on a SIP device, but there is a SIP path from the calling party to a vigilant service provider who is willing to verify the identity of the calling party. 5. The above 3 cases where the called party is on a SIP device (or its SP is SIP connected) but there are one or more hops where the identity authentication mechanism fails (that is, the identity or the identity checking information is dropped). This might be an SS7 hop for example. 6. The originating and terminating end devices are SIP connected, and desire to authenticate the caller, but there are one or more hops (possibly including the first or last hops) where the identity authentication mechanism is dropped. Brian On Jun 10, 2013, at 4:58 PM, Dave Crocker wrote: > On 6/10/2013 3:47 PM, Rosen, Brian wrote: >> ENUM, as originally envisioned, was a public database. That is a complete non-starter. >> >> ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work. >> >> What works is number delegation, and centralized databases like the US NPAC. > > > Brian, > > One of the things that would be especially helpful is to have consensus on some exemplar use cases that would aid in understanding which suggestions might be viable and which might not be. > > It's clear that a few of you have a shared model for this activity, but unfortunately it hasn't been externalized, making it accessible to the rest of the IETF community. > > So as of now, debating whether a DNS public-key mechanism is viable or can't be a debate. Only one side knows the operational criteria. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0027_01CE6688.08402510 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx MTA2NDI0OFowIwYJKoZIhvcNAQkEMRYEFIfklHkCPjSm5iDCaTJtl5K78G2nMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWUOzlmDr4zQU4nRv5YQ8T1BuCLZkY/rth7EhlkfF Xuv8BNGeDhumPP8CfyJzoDB5bqlks2ekA2B3s6EL7rfJwpo+PPfUks4Zqo6g2N1jRitnkKn+mwvm zIS7kLzbweQsbzcCRiyiPnZaqkH0Lfn0t77TLNNDYkS9AYYmsK6h2KgDwQHTV26ezRhZWnvhYMih 54UrCUndtQ+xo54VHfH+yFSbLHKgkGRoEP4ASOJMKEYp6PoayHbMt/tLwgNOgPuWY8bK1chg7PEA /LK5I5LGCTuyO9a1L9+bN+zE0a6Pn5yQFfu+bVFB6hgWaQQBhKL9e+7JjOl4ZYdeoJCuUlo7JAAA AAAAAA== ------=_NextPart_000_0027_01CE6688.08402510-- From michael.hammer@yaanatech.com Tue Jun 11 00:02: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 9BF7021F9A7D for ; Tue, 11 Jun 2013 00:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 D2cpimWqiT06 for ; Tue, 11 Jun 2013 00:01:41 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5821F9A70 for ; Tue, 11 Jun 2013 00:01:38 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 11 Jun 2013 00:01:35 -0700 From: Michael Hammer To: Michael Hammer , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81k0Rag7WUmkWt6dxCH9sPJpkslruA//+M/0CAAH9IAIADajdggAAM6fA= Date: Tue, 11 Jun 2013 07:01:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DB471@ex2k10mb2.corp.yaanatech.com> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.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.132] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0039_01CE668A.A28C5970" MIME-Version: 1.0 Cc: "Brian.Rosen@neustar.biz" , "hgs@cs.columbia.edu" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 07:02:01 -0000 ------=_NextPart_000_0039_01CE668A.A28C5970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But, I'll note having following the thread, that the issue seems to devolve to who wants to assert the presented caller ID value, sign it and be ultimately responsible for the prior chain of events. Mike p.s. I see a re-hash of prior history of various existing headers, but wondering if using what didn't work before amounts to hitting ones head against a wall and wondering why it hurts? I'm not against trying to get existing to work, but don't necessarily want to repeat history. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, June 11, 2013 9:13 AM To: hadriel.kaplan@oracle.com Cc: Brian.Rosen@neustar.biz; stir@ietf.org; hgs@cs.columbia.edu Subject: Re: [stir] Permitted spoofing If you stop it at the start, wouldn't that solve some fraction of the problem? Do we know how many calls are spoofed from the start versus from redirections? Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Saturday, June 08, 2013 10:03 PM To: Michael Hammer Cc: hgs@cs.columbia.edu; Brian.Rosen@neustar.biz; stir@ietf.org Subject: Re: [stir] Permitted spoofing I think the hope was to proactively prevent a bogus call from succeeding, as opposed to reactively hunting down the perpetrators after it happened. The latter case should be possible now, since CDRs record enough to backtrack to the upstream provider, and that provider's CDRs can find its upstream provider, etc. -hadriel On Jun 8, 2013, at 2:30 PM, Michael Hammer wrote: > Question: Do we really care how many redirections occurred in the > middle network hops if we know what the original source of the signaling was? > > Put another way, if we have a legitimate scape-goat for a problem > call, do you need to catch all the stooges all at once? > > Mike > ------=_NextPart_000_0039_01CE668A.A28C5970 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx MTA3MDEyNVowIwYJKoZIhvcNAQkEMRYEFOKahh23BgN/jibQ9k8bC+0SdtaOMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWdj8LzNLYQAX3YE5HJ1+3lMtg3gfiNs5QP15QgJo +ZhzwDoRIWG6U+abD6oitXK+2ZmsVIN5TLpEzhaeT5DT+Nf0yUZWhPM3kMmoXOIFH5JD88PPgohs ht8am3HyZdcHHU3bS5tdIf/Ij+SyEWHmemPkQPC8BgpjOgwqQMGQsLRaQFzu+nx1zMLClHxWFahJ I6oRkHdrw6FdTYhc8nlJ/wpyOzzTqsvODyGHNnxIhiJ2oQ84z/lNzmxFgvgAbfs4VuGSpCkMseOw XCtyCTf7QlxdQApCAiSP8q+NjolL855DOa2Qk6219XH/vUQI4FFlXu7rk+0KnvCJQTpWfsODeAAA AAAAAA== ------=_NextPart_000_0039_01CE668A.A28C5970-- From andrew.hutton@siemens-enterprise.com Tue Jun 11 01:19: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 B18B821F8E84 for ; Tue, 11 Jun 2013 01:19:15 -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 m07ksKRe-+61 for ; Tue, 11 Jun 2013 01:19:02 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5515C21F8B21 for ; Tue, 11 Jun 2013 01:19:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0EAC91EB84BA; Tue, 11 Jun 2013 10:19:01 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 10:19:00 +0200 From: "Hutton, Andrew" To: Richard Shockey , 'Dave Crocker' , 'Dan York' Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZkAxpr8LXDJiK0GghLzKZOKNLpkwKQsw Date: Tue, 11 Jun 2013 08:19:00 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115C5611@MCHP04MSX.global-ad.net> References: <51B67045.2060607@bbiw.net> <00f401ce6640$1bd77c10$53867430$@shockey.us> In-Reply-To: <00f401ce6640$1bd77c10$53867430$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Rosen, Brian'" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 08:19:21 -0000 on: 11 June 2013 02:08 Richard Shockey Wrote: >=20 > There are no "flash cuts" here we have to Transition. The US and the > NANP > are going to have to deal with this first since the level of SIP in the > US > and Canada network is pretty amazing. >=20 > We, the IETF, are now the actual stewards of the Public SIP Telephony > network. PSTN by another name. >=20 Just to be clear that is the WWPSTN "World Wide Public SIP Telephony Networ= k" which I would shorten to WWSN or "World Wide SIP Network" as although th= e US/Canada may currently have a large slice of the WWSN the callerid probl= ems are international. I am well aware from my own experience that a large = percentage of nuisance calls in the UK don't originate in the UK. Therefore any solution to this problem has to address the international cas= e. Andy From andrew.hutton@siemens-enterprise.com Tue Jun 11 01:41: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 F18E321F9A5D for ; Tue, 11 Jun 2013 01:41:49 -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 a0heXbWRwIbm for ; Tue, 11 Jun 2013 01:41:45 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AC15421F9A4E for ; Tue, 11 Jun 2013 01:41:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C61D023F057A; Tue, 11 Jun 2013 10:41:44 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 10:41:44 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , Brian Rosen , "stir@ietf.org" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZmeOpr8LXDJiK0GghLzKZOKNLpkwK+Dg Date: Tue, 11 Jun 2013 08:41:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115C5694@MCHP04MSX.global-ad.net> References: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> In-Reply-To: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 08:41:50 -0000 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Olle E. Johansson > Sent: 11 June 2013 06:50 > To: Brian Rosen; stir@ietf.org > Cc: Olle E. Johansson > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? >=20 >=20 > 10 jun 2013 kl. 20:58 skrev "Rosen, Brian" : >=20 > > To stop the problem, I think we need to at least start with > verification > > across SP boundaries and the termination. We want to get to the > point > > where an SP doesn't accept calls from a downstream SP that isn't > > verifiable. Long term, that might be more of an audit between SPs, > rather > > than a 100% check, and I think we would see 100% verification at the > end > > of the call (ideally the end device, but perhaps the termination SP). >=20 > Great. Have we defined "service provider" ? >=20 > I see call centers suddenly starting to sell SIP trunks. Yes one of the first things to do is to agree on terminology and probably a= t least for the IETF "Service Provider" is not the best choice. I am not su= re of the correct terminology but we are probably talking about any trust b= oundary between SIP entities. Actually in IETF terms aren't we simply talki= ng about UAC's and UAS's and maybe there is no need to define the term "Ser= vice Provider" in the IETF work. Andy >=20 > /O > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From stephen.farrell@cs.tcd.ie Tue Jun 11 02:58: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 18BE321F962A for ; Tue, 11 Jun 2013 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IKEDDyyKrmWm for ; Tue, 11 Jun 2013 02:58:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EAFBA21F949D for ; Tue, 11 Jun 2013 02:58:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58572BE8F; Tue, 11 Jun 2013 10:58:16 +0100 (IST) 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 MtZORpqbis6P; Tue, 11 Jun 2013 10:58:16 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c] (unknown [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BC73BE76; Tue, 11 Jun 2013 10:58:16 +0100 (IST) Message-ID: <51B6F4B8.3030203@cs.tcd.ie> Date: Tue, 11 Jun 2013 10:58:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <00ec01ce663b$8ab367c0$a01a3740$@shockey.us> <51B674DB.9060809@cs.tcd.ie> <1DA39C97-857B-4A1A-8265-E8E31A62DE1E@oracle.com> In-Reply-To: <1DA39C97-857B-4A1A-8265-E8E31A62DE1E@oracle.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org Subject: Re: [stir] clarity X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 09:58:44 -0000 Thanks. That (and the terq draft [1]) were useful reads for me. S. [1] http://tools.ietf.org/html/draft-peterson-terq-03 On 06/11/2013 05:31 AM, Hadriel Kaplan wrote: > > Well, it's a sensitive topic because in some ways and for some of us ENUM was a miserable failure, and for others a wild success. I don't know how much context/background you need though. I mean I don't know how much you don't already know, or what is useful to know. > > Some background on the current state of ENUM as I see it: > As originally described/envisioned ENUM was just a usage of DNS, as you know... which from the IETF's perspective means 'The DNS', and thus not only the protocol but also the architecture and massive DNS deployment, query-able by any host on the Internet, etc. This is what most people call "Public ENUM". It was a miserable failure. > > However, as DNS the *protocol* for querying numbers and getting back URIs and other stuff for various purposes, ENUM is very successful. It's just that the "DNS" servers being queried for ENUM purposes are not in any way tied into 'The DNS', but are simply servers owned by the same service provider that owns the equipment performing the queries, and are not publicly reachable. That's 'Private ENUM'. It's only within Service Providers, not in Enterprises... think of it as the Service Provider's version of LDAP. > > There is also 'Carrier ENUM' which is pseudo-private, in the sense that the servers are still not part of The DNS and are only query-able from certain providers based on a federation or some form of common agreement/relationship. Carrier ENUM exists, but is not very successful afaik. > > > Some background on using ENUM for Caller-ID verification: > The topic has come up before, although I don't know if Rich or Brian remember it. It was discussed about 5 years ago, back when we had massive email threads about the many SIP Identity problems/solutions on the mailing lists. > > There were even some drafts about it... > This one discussed the general problem area: > http://tools.ietf.org/html/draft-schwartz-sip-e164-ownership-01 > > And this one discussed using ENUM/DNS for a PKI: > http://tools.ietf.org/html/draft-darilion-sip-e164-enum-00 > > -hadriel > > > On Jun 10, 2013, at 8:52 PM, Stephen Farrell wrote: > >> >> FWIW - I have no idea how to interpret Rich's message >> and as a result am also unsure how to interpret Brian's. >> And that's about the 5th or 6th overly cryptic mail like >> that in the last few days from various folks on this >> list. So this isn't really aimed at either Brian or >> Rich but is a general plea for clarity. >> >> I'm sure there are a bunch of people on here who have >> all the context for all this. But I'm not one of 'em. >> And I bet I'm not alone. >> >> Assuming a homogeneous audience who all share the same >> painful history is yet another way to bugger up a BoF in >> my experience. Just sayin. >> >> S. >> >> On 06/11/2013 01:35 AM, Richard Shockey wrote: >>> Ah excuse me .. Why oh why does this come back to haunt me .. >>> >>> Like the Godfather III movie .. " once you think you are out, they pull you >>> back in." >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >>> Rosen, Brian >>> Sent: Monday, June 10, 2013 4:47 PM >>> To: Stephen Farrell >>> Cc: stir@ietf.org; Dave Crocker; >>> Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical >>> phone numbers survive SBCs and other middle boxes?) >>> >>> ENUM does not exist. >>> [RS> ] >>> [RS> ] It bloody well does exist.. not as e164.arpa but as private >>> instantiations all over the place as well as a access protocol to >>> Centralized Routing Databases internal to service provider networks. The IP >>> SCP. SIP Redirect is currently preferred but the protocols are still built >>> into the CSCF's. TCAP replacement.. duh let me know I can make up T-Shirts >>> for Berlin .NO TCAP. NeuStar runs the I-TRS database for the hearing >>> impaired for the FCC which is entirely based on 6116. Brian .don't go >>> there. Yes your company runs a government sponsored private instantiation >>> of 6116. Look it up people. >>> >>> We have an RFC, but we have essentially no deployment. >>> >>> ENUM, as originally envisioned, was a public database. That is a complete >>> non-starter. >>> [RS> ] >>> [RS> ] In .arpa sure but the protocol is still in very active use. The ENUM >>> WG declared success and I'm personally proud of that. Well now that you >>> kindly bring up the subject. What if .. what if you did actually looked at >>> reviving .e164.arpa but only as a tree for PKI and NO session establishment >>> data? Well Hummmm maybe there is merit to that idea. The structural >>> separation of PKI data from the underlying national numbering databases >>> could offer some interesting alternatives. Worth thinking about. Worth >>> discussing .. >>> >>> Granted I have some serious scars from the E2MD BOF's in 2010 but .. >>> >>> Well it might be worth a trial .. WOW. Gee I think I need to make a filing >>> with the FCC as part of their DA 13-1016 filing. >>> >>> http://www.fcc.gov/document/technology-transitions-policy-task-force-seeks-c >>> omment-trials >>> >>> Great Idea Brian thanks for the suggestion. What a guy!!! You are the >>> best! >>> >>> >>> >>> ENUM tried to evolve to a private database, but in most places, it was not >>> possible to organize the relationships to make it work. >>> >>> What works is number delegation, and centralized databases like the US NPAC. >>> >>> The proposed basic mechanism doesn't depend on a database of certs. The URL >>> to the cert accompanies the signature. >>> >>> One of the proposed mechanisms for handling the so-called "out of band" >>> mechanism that gets around SS7 links and SPs that don't preserve the signed >>> information does depend on such a database. I think that is a weakness. >>> There are ways to create such a database which do not depend on DNS. >>> >>> Brian >>> On Jun 10, 2013, at 4:21 PM, Stephen Farrell >>> wrote: >>> >>>> >>>> Hi >>>> >>>> On 06/07/2013 08:17 PM, Dave Crocker wrote: >>>>> (Just to be clear, I'm suggesting consideration of an approach; I'm >>>>> not sure it's the best one and I'm therefore not pushing for its >>>>> adoption, merely that it be explored.) >>>>> >>>>> Anyone can sign. They sign with a domain they own. So the signature >>>>> goes with the operator, not with the content (number, message, >>>>> whatever.) >>>> >>>> I'd also like to understand the argument here as to whether a DKIM >>>> like approach to public key retrieval is good enough or not for this >>>> application. (Note that this is orthogonal to any discussion about a >>>> DKIM-like or 4474-like signature format, I'm just asking about public >>>> key retrieval now.) >>>> >>>> As with everything, I don't need to understand it now, but I do think >>>> that a bunch of folks here are making assumptions about PKI that might >>>> turn out to be a large amount of work later, e.g. that TN delegation >>>> specific certificate chains exist, can be found and can be verified >>>> efficiently. >>>> >>>> One could easily argue that since ENUM exists and DKIM key records >>>> exist (*) a DNS lookup could be the way to get signers' public keys >>>> without requiring any 5280 processing at all at the signer or verifier. >>>> >>>> One could further argue that that'd be sufficiently "secure" even >>>> without DNSSEC, in that it'd be enough to mitigate your robocaller >>>> issues on the basis that those robocallers aren't gonna MITM or poison >>>> DNS at the verifier. >>>> >>>> A similar argument was made for DKIM: since a bad DKIM signature is >>>> the same as no signature on a mail message, there's no need to require >>>> DNSSEC to get DKIM started. >>>> >>>> While its not quite the same in this context, it may be that one could >>>> argue that a reasonable threat model would not require the signature >>>> verifier (someone/thing en-route to the callee) to strongly verify the >>>> signing public key. >>>> >>>> (Ok, I can't resist adding a feature:-) If the DKIM key selector were >>>> modified (to put it in the key value) then you might also get some >>>> level of traceability in that one could trawl the DNS for signer's >>>> public keys. I don't know if that'd be good or bad. >>>> >>>> Anyway, for now, can we make sure this gets discussed before we plump >>>> for any specific key management solution? That could be now, or at a >>>> DISPATCH session or BoF or after a WG is chartered, I don't mind, so >>>> long as it is properly considered. >>>> >>>> S. >>>> >>>> (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. >>>> For the present discussion, just assume that the keys are in the >>>> "correct" kind of RR. >>>> >>> >>> _______________________________________________ >>> 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 stephen.farrell@cs.tcd.ie Tue Jun 11 03:19: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 1D96021F8D10 for ; Tue, 11 Jun 2013 03:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 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 GyATBNlTkmwN for ; Tue, 11 Jun 2013 03:19:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E2B9F21F8AF7 for ; Tue, 11 Jun 2013 03:19:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62C9CBE7C; Tue, 11 Jun 2013 11:19:24 +0100 (IST) 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 8Sce3-mXrnwb; Tue, 11 Jun 2013 11:19:24 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c] (unknown [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 36F11BE73; Tue, 11 Jun 2013 11:19:24 +0100 (IST) Message-ID: <51B6F9AC.1040806@cs.tcd.ie> Date: Tue, 11 Jun 2013 11:19:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dan York References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , Dave Crocker , "" , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 10:19:52 -0000 So just following up on this to try to better understand where it falls over... (there is a point to that, see the end of this mail.) For now, I'll stick with assuming public ENUM even if its mythical since I think it has enough in common with any public key retrieval mechanism for the current discussion. On 06/10/2013 10:48 PM, Dan York wrote: > > On 6/10/13 5:10 PM, "Stephen Farrell" wrote: > >>> ENUM, as originally envisioned, was a public database. That is a >>> complete non-starter. >> >> Why? I mean for this application, not general phone numbers. >> >> For this, I'd just want the signer's public key at the right >> place in the DNS, where "right place" is maybe the delegation >> point (sorry if that's the wrong term). Say if the caller's >> phone is +353-1-896-1234 then the public key might be at >> +353-1-896 in the DNS so my call from TCD to somewhere can >> be signed by TCD. > > So in this scenario, the signer might be the corporate PBX, with the base > phone number at +353-1-896? > > How does the validating recipient system know to query for only that part > of the phone number? Would it need to try for the full phone number > first, then smaller parts of the number until it got back an answer? > (This would seem to introduce latency and added DNS queries.) Or did I > miss somewhere in the 100+ messages over the last few days a suggestion > for a way to tie a part of a number to what to look up? Speculating, let's say that the signed blob identifies the signer by annotating the caller number, e.g. "+353-1-896/-1234" where the "/" means that the signer is named in public ENUM using the parts of the number to the left of the "/" i.e. in this case that'd mean "+353-1-896" is the signer and I should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar) to find the public key. Anyway, my question then is: with that setup and a sensible signature format, why doesn't that work for the use-cases that Brian enumerated? If the only reason this fails is that it requires a publicly accessible database that exposes the binding between keys and sets of caller numbers, then I think any 5280-based solution will have the same problem, even if that's less obvious. For example, the SSL observatory [1] has built up an ~11million entry DB of TLS server certs. That plus another ~4million SSH host keys [2] were used to detect some badness in key generation (probably from embedded devices with bad PRNGs). For DKIM, I don't know that someone's built up such a DB, but there'd be nothing much stopping anyone who sees a bunch of email doing so if they wanted to. And we're even starting to see benefits from such large databases of public keys, e.g. RFC 6962 is one experimental spec for a way to use such a beast to mitigate bad CA (diginotar-like) behaviour. And similarly, for stir, anyone who takes a bunch of calls (or instruments a UAC to send reports of certs to a central place) could do the same. So it seems to me that its just in the nature of public key crypto that if you deploy this, then someone can build up that DB of public-keys-or-certs vs. caller-numbers. Or if you set a hard requirement to avoid that, then lots of new work would be needed to develop a PKI that tries to make that hard. Cheers, S. [1] https://www.eff.org/observatory [2] https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/ > >> And again, I'm not advocating for such a thing, just asking >> why its broken. > > I'm sure someone like Brian or Richard Shockey could give you a long list > of reasons ENUM failed. A fundamental one to me is that a public ENUM > database gave carriers and everyone access to all the meta information > about what numbers were under a carrier's responsibility. And it provided > a wonderful way for spammers to walk the DNS tree and build up a nice list > of everyone to bombard with telemarketing calls. (And there are a couple > of scripts out there that do exactly that.) > > I realize you are not suggesting ENUM for the general case of phone > numbers, but even in an abbreviated form I think it would probably expose > far more info publicly than most people are comfortable with. > > My 2 cents, > Dan > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From hgs@cs.columbia.edu Tue Jun 11 04:54: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 BDA9621F8EFE for ; Tue, 11 Jun 2013 04:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 ZSWk9tM2YIww for ; Tue, 11 Jun 2013 04:54:00 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5935321F969F for ; Tue, 11 Jun 2013 04:53:54 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5BBrqg7016844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jun 2013 07:53:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Tue, 11 Jun 2013 07:53:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C3BA6A5-EF90-4095-988B-4AA404C719A8@cs.columbia.edu> References: To: Dan York X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: stir@ietf.org Subject: Re: [stir] Alternative wording for "legitimate spoofing" - Re: Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 11:54:04 -0000 I agree that the name "legitimate spoofing" is pejorative. An alternate way of thinking about this is that a single number has = multiple legitimate assignees. =46rom a technical perspective and the = callee, they are all the same. (I don't think we want the callee to be = able to detect, for example, that it was the doctor rather than the = office, calling.) =46rom a legal perspective, there's probably a principal that controls = who else is on the "lease" and can revoke access. I think that's closer = to the reality than implying some kind of OAuth model. As a very rough = analogy, I'm thinking of a lease for an apartment or a bank account - in = day-to-day affairs, all parties on the document are treated the same.=20 If we keep this multiplicity in mind, we may not need elaborate = terminology since, technically, they are all the same. Henning On Jun 10, 2013, at 5:13 PM, Dan York wrote: >=20 > On 6/10/13 4:59 PM, "Rosen, Brian" wrote: >=20 >=20 >> If a service let's a doctor place a call from his mobile, that = appears to >> come from his office, then the source of the call is not actually the >> source of the call. If the doctor wants that, and he and his service >> provider is okay with it, he can permit it, but it's still a form of >> intentional misdirection. If he hid the source, that would be one = thing, >> but if he substitutes his office for his mobile, that is identifier >> substitution, i.e. spoofing. >>=20 >> I don't really care what we call it, but it is substituting the real >> identifier. The only difference between the service doing it and a >> scammer doing it is permission. >=20 > Yes, but I agree with Dave that here is a place where words *do* = matter. > Beyond the call centers and doctor example, there is also a part of = the > industry building applications and other forms of automation that do > legitimately operate on behalf of the original caller, typically under > contract with that original caller. There's a great deal of = innovation > and activity happening in this space. >=20 > I really don't want to send us down a grammatical rathole, but to me, > "legitimate spoofing" casts a negative tone to this area and would be = good > to be avoided. Other options could be: >=20 > - authorized third party use > - delegated calls/calling (thinking of the call center / app usage) > - roaming use (thinking of the doctor) > - authorized identifier substitution > - authorized identifier replacement >=20 > As Dave said in his nag, none of these are as catchy as "legitimate > spoofing", but I do think we should decide on one (of these above or = that > someone else has) that we use. >=20 > My 2 cents, > Dan >=20 >=20 >>=20 >> Brian >> On Jun 10, 2013, at 4:50 PM, Dave Crocker wrote: >>=20 >>> On 6/10/2013 2:59 PM, Henning Schulzrinne wrote: >>>> legitimate spoofing >>>=20 >>>=20 >>> >>>=20 >>> Forgive me, but that oxymoronic phrase is not made reasonable by = being >>> so commonly used. Spoofing is unauthorized use. (Mirriam Webster: >>> deceive, hoax.) There is not such thing as legitimate unauthorized = use. >>>=20 >>> This common mis-term has developed from a model that tries to impose >>> constraints that are not valid, but rather highlight a variation = from >>> common practice. >>>=20 >>> The reason for nagging about the phrase is that it gets people into = the >>> frame of mind of thinking that the common practice actually is the >>> model. Then this inaccuracy is propagated out through the industry = and >>> the media. >>>=20 >>> Most of the time that people use the term, they mean something like >>> 'roaming use' or 'authorized third party use'. These aren't as = catchy >>> as legitimate spoofing, but that have the minor benefit of being >>> accurate characterizations. >>>=20 >>> >>>=20 >>>=20 >>> d/ >>>=20 >>> --=20 >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >=20 >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/ >=20 >=20 >=20 >=20 >=20 From brian.rosen@neustar.biz Tue Jun 11 05:59: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 985F321F84DF for ; Tue, 11 Jun 2013 05:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=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 NenaD4xEPTXZ for ; Tue, 11 Jun 2013 05:59:15 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 733CB21F880F for ; Tue, 11 Jun 2013 05:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370955727; x=1686313945; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=3A8fU3RVMU 7/J2DRCK3wv1oL9Wa7kngrmoVr1VncmRY=; b=LKa8pQhyPzT3egs0pmyR66st9o dNpY+Wui33MuggL/+qO33reFE9bDdsaja78w4HUZWHFHRZY3DU0vFG+IjdaQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24934697; Tue, 11 Jun 2013 09:02:06 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 08:59:04 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 08:58:59 -0400 From: "Rosen, Brian" To: Dave Crocker Thread-Topic: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) Thread-Index: AQHOZiT6vkcreS1Fq0G6ZmX7V037yZkvxTuAgAAcIQCAANxHAA== Date: Tue, 11 Jun 2013 12:58:59 +0000 Message-ID: <319E54EE-B158-4F47-AFE0-AB1D3D72F7F0@neustar.biz> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <51B64AD8.6000402@bbiw.net> <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> <51B6664A.6090603@bbiw.net> In-Reply-To: <51B6664A.6090603@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vBuikC4WsFqDhE3vQcFmYw== Content-Type: text/plain; charset="Windows-1252" Content-ID: <23FFA25DD83909498E44F9DA0FEDB736@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Stephen Farrell , "stir@ietf.org" Subject: Re: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 12:59:19 -0000 Inline for a little bit of info On Jun 10, 2013, at 7:50 PM, Dave Crocker wrote: > On 6/10/2013 5:09 PM, Rosen, Brian wrote: >>> I assume that simplistic diagrams of actors for these cases is somethin= g like: >>>=20 >>>=20 >>> PSTN>SIP G/W -->+ +-> SIP>PSTN GW >>> | | >>> +-> SIP Op1..SIP OpN -+ >>> | | >>> Caller SIP UA ->+ +- Callee SIP UA >>=20 >> That middle line today is often SIP Op1..Sip OpM ->SIP>PSTN GW -> SS7 ->= PSTN>SIP GW -> SIP Op M+1.. SIP OpN >> Most of the problem is SIP originated, PSTN terminated today, but that i= s changing >=20 > Ahh. Right. So, a bit of a hack to represent, but to at least touch the= additional issue: >=20 > +---------------------------------------------+ > | ^ > V | > SS7>SIP G/W -->+ +-> SIP>SS7 GW -+ > | | | > +-> SIP Op1...SIP OpN -+ +-> Callee > | | | > Caller SIP UA ->+ +-> SIP UA -----+ >=20 >=20 >>> (However I thought that SIP allows true peer-peer exchanges, too, witho= ut mediation by an operator?) >> Yeah, but that roughly never happens with telephone number based identit= ies >=20 > OK. That's what I assumed. >=20 >=20 >>> Using "signing" and "verifying" as generic terms here, who can do each?= If any SIP-related actor is prohibited, then why? >> In theory anyone with knowledge of the identity of the originator can si= gn. In practice that means the endpoint, PBX or first SP. Anyone can vali= date. >> We would like to get to end to end validation, but we get a whole lot of= value over any entity in the path doing the validation. We would like to = get to a state where we have SPs refusing calls from downstream SPs who don= 't have valid signatures. >=20 > Glad to hear this. But of course it makes the trust model messier, since= you don't begin with trusted actors (like operators) controlling things. Delegation is reasonably trustworthy - at least you can hold the delegator = responsible. The reason this is true is that there is a delegation from a = number authority to a service provider that has some form of official recog= nition, and that entity has permission to enter calls into the PSTN. That= means it is subject to about as much regulation as possible. If that enti= ty delegates downward, the it can hold it's delegates to account, less it b= e left holding the bag. Requiring the delegator to issue a cert is the new= part. If the delegator doesn't handle it's private key securely, then a c= ompromise of that part of the number space is possible, but it's limited to= what it has been delegated. It would be better if the delegator contracte= d with an entity that was good at the job of being a CA, but we can't guara= ntee that will happen. >=20 > And it means that there's potentially a key for each number. Yes, we're heading in that direction, primarily due to number portability. = =20 >=20 > /And/ you want to allow signing by folk who don't 'own' the number. Well, the whole scheme is authority to sign is delegated. If an entity tha= t 'owns' the number authorizes someone else to use it, it would be a form o= f delegation. It would use it's key to issue a cert to the authorized enti= ty. In practice, that may be that the SP serving the end user is asked to = issue that cert by the end user. That looks like another level of delegati= on, which is just fine. Some believe we should have other forms of certs in the system. For exampl= e, someone proposed a "green carrier" cert that would work for all of calls= it originates. Others think that is not implementable (because it's too h= ard draw the line between a green carrier and a not-so-green one). There a= re other thoughts of giving certs to thinks like border elements who get ca= lls that are unsigned. They could sign them with a cert that was "I don't = know what happened before me, but here is what I got for an identity, and I= 'll sign it so it can be checked from here forward. That probably wouldn't = be all that useful for the problem at hand. >=20 >=20 >=20 >>> For example, I'd assume that a Callee SIP UA could do verification acco= rding to the architecture, even if that's not expected to be a typical oper= ational mode. If not, why not? >> Ideally, yes. There are discussions of how hard it is to get the inform= ation that is signed through the SIP network end to end in order that the e= ndpoints can do the verification. A shortcut may be to use information onl= y visible to SPs. I'd prefer not to do that, but it seems easier to some o= f the folks on the list. >>=20 >> A really typical path is bad guy to "pink" carrier to "green carrier" to= some arbitrary path that is not all SIP. If the "green" carrier verified,= and didn't accept non valid calls from the pink SP, it would stop the pro= blem. Sometimes there are a couple of SPs between pink and green (in both = the call path and color). >>=20 >> Some of us really want the call to work if there is an SS7 hop in the mi= ddle, because that is where most calls are now. If the carrier on the orig= ination side of the SS7 hop verifies, great, but if all they do is pass alo= ng the verification info, we'd like to be able to have some out-of-band way= to get it back. There are a couple of ideas on how to do that. There ha= s been an argument that by the time we could get anything deployed, we will= have eliminated that hop. I'm sanguine about that. >=20 > FWIW, at a coarse, architectural level, what you are describing is quite = similar to what DKIM confronts for email, including 'gatewaying' which in t= he email case is represented by mailing list processing -- which is formall= y a delivery to the list engine and a re-posting by it. (I did said 'coars= e'.) For DKIM, the current view is that mailing lists need to re-sign the = message; that would be an SS7>SIP gateway re-signing, here. But, of course= , it won't have the private key of the owner of the number=85 Yeah, sort of, if you squint hard enough. I don't think the analogy is goo= d enough though. DKIM doesn't have a real delegation model like this one. >=20 > Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than maili= ng lists, but from the traffic I've seen here, it doesn't sound reliable. = At a minimum, you might want to specify the core stuff without specifying t= he SS7 relaying -- include it in the thinking but not the formal spec -- an= d specify ss7 gatewaying separately. That's more than a documentation nuan= ce. There is no doubt we need to get the basic mechanism done first. There is = wide agreement that there are two separate mechanisms, with separate docume= nts. >=20 > It makes for a /far/ simpler spec, because the core model is kept quite s= imple. (I've always thought that, but watching the problems in the recent E= AI wg with this solidified the point for me.) We agree I believe >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Tue Jun 11 06:04: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 1F83421F8EBE for ; Tue, 11 Jun 2013 06:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 d3KYKvCN-oaT for ; Tue, 11 Jun 2013 06:04:18 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BC6C621F8476 for ; Tue, 11 Jun 2013 06:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370956018; x=1686313945; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=IjzT8U1084 c8e5B/Rmy/XHxSf0/w3HUhFDxQNczMoks=; b=d820pKeAEK91wWsN0hQ8HdkRWV qF0avOFOEB02YAViQrGTZXlpNET8WDVgCzO/uvpFvEIJg6OR+/tgyBz7Y1HA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24935089; Tue, 11 Jun 2013 09:06:57 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 09:03:55 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 09:03:52 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81QVR2lI4PHEaFqY34c3fHK5ksZHCAgAADK4CAAAkdAIAD3+GAgABy0gA= Date: Tue, 11 Jun 2013 13:03:51 +0000 Message-ID: <02A4880B-8DBE-48D8-A5EC-DD82EC282527@neustar.biz> References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: arvAzsd4OTv0gT88bMIzbg== Content-Type: text/plain; charset="us-ascii" Content-ID: <78A9833D5BA5C04E9DB0930870D385C7@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 13:04:25 -0000 For the problems we're aiming at (robocalling, vishing and swatting), they = are 100% spoofed from the start. MITM is a potential problem, which would = be desirable to cut off, but it's not the stated problem we're trying to so= lve. There may be some number of service providers in the path that are tolerant= of the problem, but not really complicit. The goal is to make them be in= tolerant of their customers not providing verifiable identity. Brian On Jun 11, 2013, at 2:12 AM, Michael Hammer = wrote: > If you stop it at the start, wouldn't that solve some fraction of the > problem? >=20 > Do we know how many calls are spoofed from the start versus from > redirections? >=20 > Mike >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 > Sent: Saturday, June 08, 2013 10:03 PM > To: Michael Hammer > Cc: hgs@cs.columbia.edu; Brian.Rosen@neustar.biz; stir@ietf.org > Subject: Re: [stir] Permitted spoofing >=20 >=20 > I think the hope was to proactively prevent a bogus call from succeeding,= as > opposed to reactively hunting down the perpetrators after it happened. T= he > latter case should be possible now, since CDRs record enough to backtrack= to > the upstream provider, and that provider's CDRs can find its upstream > provider, etc. >=20 > -hadriel >=20 >=20 > On Jun 8, 2013, at 2:30 PM, Michael Hammer > wrote: >=20 >> Question: Do we really care how many redirections occurred in the=20 >> middle network hops if we know what the original source of the signaling > was? >>=20 >> Put another way, if we have a legitimate scape-goat for a problem=20 >> call, do you need to catch all the stooges all at once? >>=20 >> Mike >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Tue Jun 11 06:05: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 F362521F8FE5 for ; Tue, 11 Jun 2013 06:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 37PeUVShPCPV for ; Tue, 11 Jun 2013 06:05:27 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D322C21F85D1 for ; Tue, 11 Jun 2013 06:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370956390; x=1686316101; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=JY/SK7EIT+ fTwrPD7/bMYCxa4obLq5kFXe+fx03NBGA=; b=mI9ikl79HpldnqTPIWlOsCxSg+ IC2eLisQO95ZEPBdgtKwrXZPclLvre1E8bWyTQhhKcVDtofi6FyzL/PjdPKQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26092514; Tue, 11 Jun 2013 09:13:09 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 09:04:58 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 09:04:53 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81QVR2lI4PHEaFqY34c3fHK5ksZHCAgAADK4CAAAkdAIAD3+GAgAANmgCAAGWCAA== Date: Tue, 11 Jun 2013 13:04:53 +0000 Message-ID: References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB471@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DB471@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +0z6qVJnk43n/wWwsuPJPA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 13:05:31 -0000 Of course! =20 On Jun 11, 2013, at 3:01 AM, Michael Hammer = wrote: > But, I'll note having following the thread, that the issue seems to devol= ve > to=20 > who wants to assert the presented caller ID value, sign it and=20 > be ultimately responsible for the prior chain of events. >=20 > Mike >=20 > p.s. I see a re-hash of prior history of various existing headers, but > wondering=20 > if using what didn't work before amounts to hitting ones head against a w= all > and wondering why it hurts? > I'm not against trying to get existing to work, but don't necessarily wan= t > to repeat history. >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Michael Hammer > Sent: Tuesday, June 11, 2013 9:13 AM > To: hadriel.kaplan@oracle.com > Cc: Brian.Rosen@neustar.biz; stir@ietf.org; hgs@cs.columbia.edu > Subject: Re: [stir] Permitted spoofing >=20 > If you stop it at the start, wouldn't that solve some fraction of the > problem? >=20 > Do we know how many calls are spoofed from the start versus from > redirections? >=20 > Mike >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Saturday, June 08, 2013 10:03 PM > To: Michael Hammer > Cc: hgs@cs.columbia.edu; Brian.Rosen@neustar.biz; stir@ietf.org > Subject: Re: [stir] Permitted spoofing >=20 >=20 > I think the hope was to proactively prevent a bogus call from succeeding,= as > opposed to reactively hunting down the perpetrators after it happened. T= he > latter case should be possible now, since CDRs record enough to backtrack= to > the upstream provider, and that provider's CDRs can find its upstream > provider, etc. >=20 > -hadriel >=20 >=20 > On Jun 8, 2013, at 2:30 PM, Michael Hammer > wrote: >=20 >> Question: Do we really care how many redirections occurred in the=20 >> middle network hops if we know what the original source of the signaling > was? >>=20 >> Put another way, if we have a legitimate scape-goat for a problem=20 >> call, do you need to catch all the stooges all at once? >>=20 >> Mike >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Tue Jun 11 06:11: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 1277621F9458 for ; Tue, 11 Jun 2013 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 Cdh64-WUb99F for ; Tue, 11 Jun 2013 06:11:16 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E93E021F8956 for ; Tue, 11 Jun 2013 06:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370956206; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=GFNljQxbjf JGQRn7+vDmNGX1Ch8AAmlV/7n4H8LgK0I=; b=GeIP9/kMgseOuJHkEL0EH/I4DT B0vVZm9aYZTqEDYw9QiZNBRIdjZUQKLZU0/+5mBVJ0cW6/QnNa8GALsrjZdg== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20824026; Tue, 11 Jun 2013 09:10:05 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 09:10:58 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 09:10:55 -0400 From: "Rosen, Brian" To: "Olle E. Johansson" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZeTRM5W7894jfk6JBRmvbH4VTZkvTsuA///C0oCAAEsfgIAABKAAgAAYjACAABLAAP//wHIAgAD5FICAAHtMgA== Date: Tue, 11 Jun 2013 13:10:55 +0000 Message-ID: <10E9C794-70A8-41CF-80B3-61174A6F2312@neustar.biz> References: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> In-Reply-To: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: yO0GR1bn6D62Vad+X0ZBOQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <7BE2309B9C01C845BE824E132182E475@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 13:11:20 -0000 Yeah, you are correct. It's one of the reasons we need to bring PBX/Sip Tr= unk into this discussion. The notion of "Service Provider" is broad. I'm = not sure we need a new term, but it's not equivalent to "carrier". It's a= ny independent SIP or SS7 entity in the path. Another way to look at it, it's any entity that might get a visit from a la= w enforcement agency tracking an illegal robocall/vish/swat that had a down= stream entity they could pass the LE agency off on by showing the LE that i= dentity was good when it got to the "SP". Brian On Jun 11, 2013, at 1:49 AM, Olle E. Johansson wrote: >=20 > 10 jun 2013 kl. 20:58 skrev "Rosen, Brian" : >=20 >> To stop the problem, I think we need to at least start with verification >> across SP boundaries and the termination. We want to get to the point >> where an SP doesn't accept calls from a downstream SP that isn't >> verifiable. Long term, that might be more of an audit between SPs, rathe= r >> than a 100% check, and I think we would see 100% verification at the end >> of the call (ideally the end device, but perhaps the termination SP). >=20 > Great. Have we defined "service provider" ? >=20 > I see call centers suddenly starting to sell SIP trunks. >=20 > /O > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Tue Jun 11 06:13: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 3175721F94E1 for ; Tue, 11 Jun 2013 06:13:24 -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 Ycw6BZX0LeE5 for ; Tue, 11 Jun 2013 06:13:15 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CA00B21F8956 for ; Tue, 11 Jun 2013 06:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370956333; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=qK647SFK37 WoW6x54jlcc8cE2tRODmppnvORzDkB6OQ=; b=CLWXpBRl+6Dkirf1TOTLkgwfbG OTaVtYexyfXLVhSJa8e80aMZLsMDHSPxCvCORHLv5lRIqKoS1icFSReQSRXg== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20824096; Tue, 11 Jun 2013 09:12:12 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 09:13:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 09:13:03 -0400 From: "Rosen, Brian" To: "Hutton, Andrew" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZn+DERu2bouCq0CbSpO4UJ/XY5kwwNwA Date: Tue, 11 Jun 2013 13:13:02 +0000 Message-ID: References: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115C5694@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115C5694@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: PACN/X0wJrAxsqMdadETjA== Content-Type: text/plain; charset="us-ascii" Content-ID: <73F8EE9B779AB74DACFDF4905A3BB7F2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "Olle E. Johansson" , "stir@ietf.org" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 13:13:24 -0000 I'm still okay with service provider. It's not UAC/UAS for sure - a servic= e provider that only had proxies could verify, and they could be in the del= egation chain. "Trust boundaries" is getting at the idea. Brian On Jun 11, 2013, at 4:41 AM, "Hutton, Andrew" wrote: >=20 >=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Olle E. Johansson >> Sent: 11 June 2013 06:50 >> To: Brian Rosen; stir@ietf.org >> Cc: Olle E. Johansson >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other >> middle boxes? >>=20 >>=20 >> 10 jun 2013 kl. 20:58 skrev "Rosen, Brian" : >>=20 >>> To stop the problem, I think we need to at least start with >> verification >>> across SP boundaries and the termination. We want to get to the >> point >>> where an SP doesn't accept calls from a downstream SP that isn't >>> verifiable. Long term, that might be more of an audit between SPs, >> rather >>> than a 100% check, and I think we would see 100% verification at the >> end >>> of the call (ideally the end device, but perhaps the termination SP). >>=20 >> Great. Have we defined "service provider" ? >>=20 >> I see call centers suddenly starting to sell SIP trunks. >=20 > Yes one of the first things to do is to agree on terminology and probably= at least for the IETF "Service Provider" is not the best choice. I am not = sure of the correct terminology but we are probably talking about any trust= boundary between SIP entities. Actually in IETF terms aren't we simply tal= king about UAC's and UAS's and maybe there is no need to define the term "S= ervice Provider" in the IETF work. >=20 >=20 > Andy >=20 >>=20 >> /O >> _______________________________________________ >> 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 brian.rosen@neustar.biz Tue Jun 11 06:34: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 A296C21F88FB for ; Tue, 11 Jun 2013 06:34:13 -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 gapvQuyUQ-rL for ; Tue, 11 Jun 2013 06:34:09 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5257B21F8934 for ; Tue, 11 Jun 2013 06:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370958104; x=1686316101; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=OUrivl+Y3R IojME9tXtcbsEocMTmAGxD30S9vhkHMgk=; b=kSZ1LfAXX/KXXdot7FmSBhCePw S3QAlR0RCc7H/EpNOQXqUIoNKH4bVLIsi9a2TJyP0YSJeoiAR8Ln0FwZJVMA== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26093984; Tue, 11 Jun 2013 09:41:43 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 09:33:32 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 09:33:30 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvy4AgADR7ACAADY6gA== Date: Tue, 11 Jun 2013 13:33:29 +0000 Message-ID: <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> References: <51B6F9AC.1040806@cs.tcd.ie> In-Reply-To: <51B6F9AC.1040806@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: F7G18PYvsJRmLx9VLQLnEw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Dave Crocker , Dan York , "" , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 13:34:13 -0000 1. Number delegation doesn't follow a tree. You can be delegated 25 number= s in a range. We are rapidly evolving to a delegation of 1 number. The tr= ee than ENUM gives you doesn't match the delegation model, and thus the cer= t model. You can force fit it by just expanding the whole tree out, but th= at is inefficient and silly. We know how to do a simple web service query = with a telephone number and return an answer. Don't make things more compl= icated. 2. The global root of the tree (e164.arpa) has been a nightmare 3. SIP Identity sends the URI of the cert in the signaling with the call. = You don't need a database to retrieve it. One of the proposed additional m= echanisms did need a way for the originator to discover the cert for the te= rmination. =20 4. Unless there is some entity in a country that actually issues ALL the ce= rts, putting the certs in a publicly accessible database raises privacy and= business concerns that I (and a lot of other people) think are insurmounta= ble. You can't be able to tell which SP serves which numbers. That might = change over time, but right now, it's impossible. I understand your observ= ation about building up a DB of certs. I expect it to happen. But making = the DB public today is a non-starter. =20 Brian On Jun 11, 2013, at 6:19 AM, Stephen Farrell wr= ote: >=20 > So just following up on this to try to better understand > where it falls over... (there is a point to that, see the > end of this mail.) >=20 > For now, I'll stick with assuming public ENUM even if its > mythical since I think it has enough in common with any > public key retrieval mechanism for the current discussion. >=20 > On 06/10/2013 10:48 PM, Dan York wrote: >>=20 >> On 6/10/13 5:10 PM, "Stephen Farrell" wrote: >>=20 >>>> ENUM, as originally envisioned, was a public database. That is a >>>> complete non-starter. >>>=20 >>> Why? I mean for this application, not general phone numbers. >>>=20 >>> For this, I'd just want the signer's public key at the right >>> place in the DNS, where "right place" is maybe the delegation >>> point (sorry if that's the wrong term). Say if the caller's >>> phone is +353-1-896-1234 then the public key might be at >>> +353-1-896 in the DNS so my call from TCD to somewhere can >>> be signed by TCD. >>=20 >> So in this scenario, the signer might be the corporate PBX, with the bas= e >> phone number at +353-1-896? >>=20 >> How does the validating recipient system know to query for only that par= t >> of the phone number? Would it need to try for the full phone number >> first, then smaller parts of the number until it got back an answer? >> (This would seem to introduce latency and added DNS queries.) Or did = I >> miss somewhere in the 100+ messages over the last few days a suggestion >> for a way to tie a part of a number to what to look up? >=20 > Speculating, let's say that the signed blob identifies the > signer by annotating the caller number, e.g. "+353-1-896/-1234" > where the "/" means that the signer is named in public ENUM > using the parts of the number to the left of the "/" i.e. in > this case that'd mean "+353-1-896" is the signer and I > should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar) > to find the public key. >=20 > Anyway, my question then is: with that setup and a sensible > signature format, why doesn't that work for the use-cases > that Brian enumerated? >=20 > If the only reason this fails is that it requires a publicly > accessible database that exposes the binding between keys and > sets of caller numbers, then I think any 5280-based solution > will have the same problem, even if that's less obvious. >=20 > For example, the SSL observatory [1] has built up an ~11million > entry DB of TLS server certs. That plus another ~4million > SSH host keys [2] were used to detect some badness in key > generation (probably from embedded devices with bad PRNGs). > For DKIM, I don't know that someone's built up such a DB, > but there'd be nothing much stopping anyone who sees a bunch > of email doing so if they wanted to. And we're even starting > to see benefits from such large databases of public keys, > e.g. RFC 6962 is one experimental spec for a way to use > such a beast to mitigate bad CA (diginotar-like) behaviour. >=20 > And similarly, for stir, anyone who takes a bunch of calls > (or instruments a UAC to send reports of certs to a central > place) could do the same. >=20 > So it seems to me that its just in the nature of public key > crypto that if you deploy this, then someone can build up > that DB of public-keys-or-certs vs. caller-numbers. Or if > you set a hard requirement to avoid that, then lots of new > work would be needed to develop a PKI that tries to make > that hard. >=20 > Cheers, > S. >=20 > [1] https://www.eff.org/observatory > [2] > https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-pan= ic-over-factorable-keys-just-mind-your-ps-and-qs/ >=20 >>=20 >>> And again, I'm not advocating for such a thing, just asking >>> why its broken. >>=20 >> I'm sure someone like Brian or Richard Shockey could give you a long lis= t >> of reasons ENUM failed. A fundamental one to me is that a public ENUM >> database gave carriers and everyone access to all the meta information >> about what numbers were under a carrier's responsibility. And it provid= ed >> a wonderful way for spammers to walk the DNS tree and build up a nice li= st >> of everyone to bombard with telemarketing calls. (And there are a couple >> of scripts out there that do exactly that.) >>=20 >> I realize you are not suggesting ENUM for the general case of phone >> numbers, but even in an abbreviated form I think it would probably expos= e >> far more info publicly than most people are comfortable with. >>=20 >> My 2 cents, >> Dan >>=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 dhc2@dcrocker.net Tue Jun 11 07:26: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 C8F9521F994A for ; Tue, 11 Jun 2013 07:26:11 -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 vJovcjYzQLRe for ; Tue, 11 Jun 2013 07:25:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11E21F99F4 for ; Tue, 11 Jun 2013 07:25:46 -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 r5BEPMjT015777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 07:25:26 -0700 Message-ID: <51B7334E.9000105@dcrocker.net> Date: Tue, 11 Jun 2013 07:25:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <51B64AD8.6000402@bbiw.net> <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> <51B6664A.6090603@bbiw.net> <319E54EE-B158-4F47-AFE0-AB1D3D72F7F0@neustar.biz> In-Reply-To: <319E54EE-B158-4F47-AFE0-AB1D3D72F7F0@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 11 Jun 2013 07:25:28 -0700 (PDT) Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) 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, 11 Jun 2013 14:26:15 -0000 On 6/11/2013 5:58 AM, Rosen, Brian wrote: > On Jun 10, 2013, at 7:50 PM, Dave Crocker wrote: >> >> Glad to hear this. But of course it makes the trust model messier, >> since you don't begin with trusted actors (like operators) >> controlling things. >> > Delegation is reasonably trustworthy - at least you can hold the > delegator responsible. I think I've heard different assertions of requirement on the list about that. What you cite here is 'accountability', which means the ability do to post hoc (after the problem) followup. I've heard others cite 'prevention' as the requirement, which means a pre hoc capability. Of course, these are hugely different constraints, with that latter being far more onerous, or at least technically and operationally demanding. > The reason this is true is that there is a > delegation from a number authority to a service provider that has > some form of official recognition, and that entity has permission to > enter calls into the PSTN. This gets back to a question that has come up a few times: Does the trust model encompass -- or, at least, rely on -- only a relatively small number of specially-authorized operators, who are very highly vetted and accountable; or does it potentially encompass anyone with a SIP client? This is why I've pressed for clarifying the statement and depiction about actors in the STIR scenario. I think you suggest the answer a bit farther down, but I wanted to call out the core question here. If the requirement is to permit a calling SIP UA to assert the ID, then the set of participants is billions and accountability is an entirely different game. An intermediate place is a model of ID assertion by any "organization"; that is, anyone operating a SIP server along the path. It could still be far more unruly that limiting to a relatively tiny, regulated core, but it's some orders of magnitude smaller than "everyone and every device". Your note saying, "the notion of 'Service Provider' is broad. I'm not sure we need a new term, but it's not equivalent to 'carrier'. It's any independent SIP or SS7 entity in the path." frankly appears to match the current email operational model... (By way of comparison, DKIM's architectural model allows anyone along the path to sign, including the author's UA; however the ID is a domain name, which best scales to hosts and not users -- generally.) > That means it is subject to about as > much regulation as possible.If that entity delegates downward, the > it can hold it's delegates to account, less it be left holding the > bag. This excludes a true peer-to-peer operation, without regulated service providers. I thought an earlier posting said the goal was to include P2P. > Requiring the delegator to issue a cert is the new part. If > the delegator doesn't handle it's private key securely, then a > compromise of that part of the number space is possible, but it's > limited to what it has been delegated. It would be better if the > delegator contracted with an entity that was good at the job of being > a CA, but we can't guarantee that will happen. > >> >> And it means that there's potentially a key for each number. > Yes, we're heading in that direction, primarily due to number portability. dandy. >> /And/ you want to allow signing by folk who don't 'own' the number. > Well, the whole scheme is authority to sign is delegated. If an entity that 'owns' the number authorizes someone else to use it, it would be a form of delegation. It would use it's key to issue a cert to the authorized entity. In practice, that may be that the SP serving the end user is asked to issue that cert by the end user. That looks like another level of delegation, which is just fine. OK. This defines a trust model comprising a core of regulated and highly accountable operators that provide a base of assurance, but permitting delegation of trust down a hierarchy. That seems to be different than your statement that I quoted, above. However it does seem to match the current PSTN global model, but that it excludes true P2P. > Some believe we should have other forms of certs in the system. For example, someone proposed a "green carrier" cert that would work for all of calls it originates. Others think that is not implementable (because it's too hard draw the line between a green carrier and a not-so-green one). There are other thoughts of giving certs to thinks like border elements who get calls that are unsigned. They could sign them with a cert that was "I don't know what happened before me, but here is what I got for an identity, and I'll sign it so it can be checked from here forward. That probably wouldn't be all that useful for the problem at hand. This moves the trust question from "assertion by fiat involving regulation" to one of "reputation". Again, these impose vastly different design and operation requirements. >> FWIW, at a coarse, architectural level, what you are describing is quite similar to what DKIM confronts for email, including 'gatewaying' which in the email case is represented by mailing list processing -- which is formally a delivery to the list engine and a re-posting by it. (I did said 'coarse'.) For DKIM, the current view is that mailing lists need to re-sign the message; that would be an SS7>SIP gateway re-signing, here. But, of course, it won't have the private key of the owner of the number… > Yeah, sort of, if you squint hard enough. I don't think the analogy is good enough though. DKIM doesn't have a real delegation model like this one. It delegates name authentication, but not trust. DKIM doesn't assert trust, except for a signer's assertion of the name. Trust is an overlay mechanism, built up from the validation of the (domain) name use. A detriment to that model is the need to then define the trust overlay. The benefit of that model is that it allows exploring different instantiations of the trust layer. Where trust is a complex topic, that's a win. It might also be a necessity. One concern is that efforts to create explicit 'trust' mechanisms over the global/public Internet has generally been highly problematic. Hence reliance on a model with a small, regulated core is appealing, but only if it really is the required long-term model. As I've noted, I think some folk are asserting expectations that seems to call that model into question. (For this round, I'm not trying to express my own architectural preferences, but merely get clarity on what's being said.) >> Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than mailing lists, but from the traffic I've seen here, it doesn't sound reliable. At a minimum, you might want to specify the core stuff without specifying the SS7 relaying -- include it in the thinking but not the formal spec -- and specify ss7 gatewaying separately. That's more than a documentation nuance. > There is no doubt we need to get the basic mechanism done first. There is wide agreement that there are two separate mechanisms, with separate documents. >> >> It makes for a /far/ simpler spec, because the core model is kept quite simple. (I've always thought that, but watching the problems in the recent EAI wg with this solidified the point for me.) > We agree I believe uh oh... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Tue Jun 11 07:46: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 AF66C21F9925 for ; Tue, 11 Jun 2013 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 xOuQhn6h4C1v for ; Tue, 11 Jun 2013 07:45:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD5C421F9997 for ; Tue, 11 Jun 2013 07:45:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 17ABDBE39; Tue, 11 Jun 2013 15:45:33 +0100 (IST) 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 jGMSGw41AkU5; Tue, 11 Jun 2013 15:45:33 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c] (unknown [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA109BE20; Tue, 11 Jun 2013 15:45:32 +0100 (IST) Message-ID: <51B7380D.1020706@cs.tcd.ie> Date: Tue, 11 Jun 2013 15:45:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> In-Reply-To: <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , Dan York , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 14:46:00 -0000 Hi Brian, So I didn't hear you say that the scheme outlined failed to meet the use-cases other than in respect of the public key retrieval aspect. That seems to imply that the role of any CAs in a PKI here may differ a lot from e.g. TLS. Or to put it another way, the level of assurance for public keys needed may well be pretty modest, if the threat model does not need to consider an on-path, MITM-type attacker. I'm also confused as to why its a non-starter to have a public database of public keys and phone numbers, but is ok that anyone can build that database themselves, with fairly modest effort. That seems odd to me anyway. (To be clear, I do consider de-referencing a URL for a public key or cert as a DB-lookup.) My conclusion so far is that this effort should be quite careful to not require a complex PKI if that's not really needed. S. On 06/11/2013 02:33 PM, Rosen, Brian wrote: > 1. Number delegation doesn't follow a tree. You can be delegated 25 numbers in a range. We are rapidly evolving to a delegation of 1 number. The tree than ENUM gives you doesn't match the delegation model, and thus the cert model. You can force fit it by just expanding the whole tree out, but that is inefficient and silly. We know how to do a simple web service query with a telephone number and return an answer. Don't make things more complicated. > 2. The global root of the tree (e164.arpa) has been a nightmare > 3. SIP Identity sends the URI of the cert in the signaling with the call. You don't need a database to retrieve it. One of the proposed additional mechanisms did need a way for the originator to discover the cert for the termination. > 4. Unless there is some entity in a country that actually issues ALL the certs, putting the certs in a publicly accessible database raises privacy and business concerns that I (and a lot of other people) think are insurmountable. You can't be able to tell which SP serves which numbers. That might change over time, but right now, it's impossible. I understand your observation about building up a DB of certs. I expect it to happen. But making the DB public today is a non-starter. > > Brian > > > On Jun 11, 2013, at 6:19 AM, Stephen Farrell wrote: > >> >> So just following up on this to try to better understand >> where it falls over... (there is a point to that, see the >> end of this mail.) >> >> For now, I'll stick with assuming public ENUM even if its >> mythical since I think it has enough in common with any >> public key retrieval mechanism for the current discussion. >> >> On 06/10/2013 10:48 PM, Dan York wrote: >>> >>> On 6/10/13 5:10 PM, "Stephen Farrell" wrote: >>> >>>>> ENUM, as originally envisioned, was a public database. That is a >>>>> complete non-starter. >>>> >>>> Why? I mean for this application, not general phone numbers. >>>> >>>> For this, I'd just want the signer's public key at the right >>>> place in the DNS, where "right place" is maybe the delegation >>>> point (sorry if that's the wrong term). Say if the caller's >>>> phone is +353-1-896-1234 then the public key might be at >>>> +353-1-896 in the DNS so my call from TCD to somewhere can >>>> be signed by TCD. >>> >>> So in this scenario, the signer might be the corporate PBX, with the base >>> phone number at +353-1-896? >>> >>> How does the validating recipient system know to query for only that part >>> of the phone number? Would it need to try for the full phone number >>> first, then smaller parts of the number until it got back an answer? >>> (This would seem to introduce latency and added DNS queries.) Or did I >>> miss somewhere in the 100+ messages over the last few days a suggestion >>> for a way to tie a part of a number to what to look up? >> >> Speculating, let's say that the signed blob identifies the >> signer by annotating the caller number, e.g. "+353-1-896/-1234" >> where the "/" means that the signer is named in public ENUM >> using the parts of the number to the left of the "/" i.e. in >> this case that'd mean "+353-1-896" is the signer and I >> should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar) >> to find the public key. >> >> Anyway, my question then is: with that setup and a sensible >> signature format, why doesn't that work for the use-cases >> that Brian enumerated? >> >> If the only reason this fails is that it requires a publicly >> accessible database that exposes the binding between keys and >> sets of caller numbers, then I think any 5280-based solution >> will have the same problem, even if that's less obvious. >> >> For example, the SSL observatory [1] has built up an ~11million >> entry DB of TLS server certs. That plus another ~4million >> SSH host keys [2] were used to detect some badness in key >> generation (probably from embedded devices with bad PRNGs). >> For DKIM, I don't know that someone's built up such a DB, >> but there'd be nothing much stopping anyone who sees a bunch >> of email doing so if they wanted to. And we're even starting >> to see benefits from such large databases of public keys, >> e.g. RFC 6962 is one experimental spec for a way to use >> such a beast to mitigate bad CA (diginotar-like) behaviour. >> >> And similarly, for stir, anyone who takes a bunch of calls >> (or instruments a UAC to send reports of certs to a central >> place) could do the same. >> >> So it seems to me that its just in the nature of public key >> crypto that if you deploy this, then someone can build up >> that DB of public-keys-or-certs vs. caller-numbers. Or if >> you set a hard requirement to avoid that, then lots of new >> work would be needed to develop a PKI that tries to make >> that hard. >> >> Cheers, >> S. >> >> [1] https://www.eff.org/observatory >> [2] >> https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/ >> >>> >>>> And again, I'm not advocating for such a thing, just asking >>>> why its broken. >>> >>> I'm sure someone like Brian or Richard Shockey could give you a long list >>> of reasons ENUM failed. A fundamental one to me is that a public ENUM >>> database gave carriers and everyone access to all the meta information >>> about what numbers were under a carrier's responsibility. And it provided >>> a wonderful way for spammers to walk the DNS tree and build up a nice list >>> of everyone to bombard with telemarketing calls. (And there are a couple >>> of scripts out there that do exactly that.) >>> >>> I realize you are not suggesting ENUM for the general case of phone >>> numbers, but even in an abbreviated form I think it would probably expose >>> far more info publicly than most people are comfortable with. >>> >>> My 2 cents, >>> Dan >>> >>> >>> _______________________________________________ >>> 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 andrew.hutton@siemens-enterprise.com Tue Jun 11 07:53: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 3F22521F9A11 for ; Tue, 11 Jun 2013 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Z7XAQaDgIWwK for ; Tue, 11 Jun 2013 07:53:23 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF9321F93F8 for ; Tue, 11 Jun 2013 07:53:23 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 304C71EB85E9; Tue, 11 Jun 2013 16:53:22 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 16:53:22 +0200 From: "Hutton, Andrew" To: "Rosen, Brian" Thread-Topic: [stir] Can canonical phone numbers survive SBCs and other middle boxes? Thread-Index: AQHOZmeOpr8LXDJiK0GghLzKZOKNLpkwK+DggAAwlwCAADnE0A== Date: Tue, 11 Jun 2013 14:53:21 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115C603F@MCHP04MSX.global-ad.net> References: <44AD94C6-49FF-41F3-8F35-BEAE418EE37C@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115C5694@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "Olle E. Johansson" Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 14:53:27 -0000 Well I think we need to talk in terms of SIP entities and "service provider= " is not really one and if we use that term then many companies might think= the work does not apply to them when it really does. Agree with your comments on proxies which can of course verify identity and= we would need procedures to describe proxy behavior. Regards Andy > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: 11 June 2013 14:13 > To: Hutton, Andrew > Cc: Olle E. Johansson; Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other > middle boxes? >=20 > I'm still okay with service provider. It's not UAC/UAS for sure - a > service provider that only had proxies could verify, and they could be > in the delegation chain. >=20 > "Trust boundaries" is getting at the idea. >=20 > Brian >=20 > On Jun 11, 2013, at 4:41 AM, "Hutton, Andrew" enterprise.com> wrote: >=20 > > > > > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of > >> Olle E. Johansson > >> Sent: 11 June 2013 06:50 > >> To: Brian Rosen; stir@ietf.org > >> Cc: Olle E. Johansson > >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and > other > >> middle boxes? > >> > >> > >> 10 jun 2013 kl. 20:58 skrev "Rosen, Brian" > : > >> > >>> To stop the problem, I think we need to at least start with > >> verification > >>> across SP boundaries and the termination. We want to get to the > >> point > >>> where an SP doesn't accept calls from a downstream SP that isn't > >>> verifiable. Long term, that might be more of an audit between SPs, > >> rather > >>> than a 100% check, and I think we would see 100% verification at > the > >> end > >>> of the call (ideally the end device, but perhaps the termination > SP). > >> > >> Great. Have we defined "service provider" ? > >> > >> I see call centers suddenly starting to sell SIP trunks. > > > > Yes one of the first things to do is to agree on terminology and > probably at least for the IETF "Service Provider" is not the best > choice. I am not sure of the correct terminology but we are probably > talking about any trust boundary between SIP entities. Actually in IETF > terms aren't we simply talking about UAC's and UAS's and maybe there is > no need to define the term "Service Provider" in the IETF work. > > > > > > Andy > > > >> > >> /O > >> _______________________________________________ > >> 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 brian.rosen@neustar.biz Tue Jun 11 08: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 F32FB21F8F2F for ; Tue, 11 Jun 2013 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 3-ivYLAMP5A8 for ; Tue, 11 Jun 2013 08:14:07 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BFF9C21F8C40 for ; Tue, 11 Jun 2013 08:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370964128; x=1686321501; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Fk2dNFyM1R sxu/2TdKmJYZceCq4ZlHssy36jMWwMYRI=; b=RGsqIV3sP7DSv+fO+1zNrGwA5v wL4ORTo/9DkjPRbhCs293nzscl791Fh0rRyDgnM/Ma6tOnvd9ix9DwzIg7rg== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26099202; Tue, 11 Jun 2013 11:22:07 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 11:13:55 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 11:13:52 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) Thread-Index: AQHOZiT6vkcreS1Fq0G6ZmX7V037yZkvxTuAgAAcIQCAANxHAIAAGB8AgAANjwA= Date: Tue, 11 Jun 2013 15:13:51 +0000 Message-ID: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <51B64AD8.6000402@bbiw.net> <1ED82FD7-1277-4860-8655-25C2C7634F16@neustar.biz> <51B6664A.6090603@bbiw.net> <319E54EE-B158-4F47-AFE0-AB1D3D72F7F0@neustar.biz> <51B7334E.9000105@dcrocker.net> In-Reply-To: <51B7334E.9000105@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ASRrXbKQT109roIQBlFVDQ== Content-Type: text/plain; charset="Windows-1252" Content-ID: <15FB618B1D31E14087428BC39335ECBC@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Stephen Farrell , "stir@ietf.org" Subject: Re: [stir] Feeble diagram (was - Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 15:14:11 -0000 Our GOAL is to have valid identity put on the call at the outset, and at le= ast potentially verifiable all along the path. The GOAL is end to end veri= fiability. To solve the immediate problem, it doesn't have to be end to end. An SP ea= rly on the path may be able to add the identity. It can to be some entity = in the middle rejecting the call because it does not have a good identity. We delegate numbers now. This works well enough. Delegation is changing (= slowly), because we have more players. Delegation works because the upstr= eam entity gets a relatively large block of numbers, and then resells some = smaller block of numbers to the downstream entity. It's used the case tha= t the initial delegation from the national number authority was very large = (10,000 numbers for example). Today, it's common to get 1,000 at a time, bu= t that is changing and soon the size of the allocation may be completely va= riable, or at least very variable, down to a request for one number. Right at the moment, in nearly every case, the call path mirrors the delega= tion path. That won't be true for much longer - some entities may be able = to get numbers from the national number plan without having the call path m= irror the delegation path and service providers of all kinds are making arr= angements to exchange traffic that effectively short circuits the delegatio= n path. Need to keep that in mind. Ultimately, delegation is traceable, although it's hard to do the trace. H= owever, at every step, there is some kind of transaction where the upstream= entity grants the downstream entity use of a set of numbers. Delegation w= orks right down to the end user (which is a delegation of 1 number, recogni= zing that a PBX could be considered an "end user" and have more than one nu= mber delegated to it. It really is very reasonable to enhance this delega= tion with certs. When you get a cert from the upstream entity, it's proof = that the transaction took place, and you are authorized to use the numbers.= "Trust" doesn't really mean much at this stage. The cert is good proof i= f the keys are managed well, and it's meaningless if the keys are compromis= ed. There is a chain of keys, matching the delegation. This is a pretty s= imple model, based on an existing, working process. If the national number= authority controls its process well enough, then misuse of keys is traceab= le down the chain to some point where someone has not handled their keys we= ll. The remedy is to invalidate the chain at that point, which only affect= s the number space below that point. If the size of the original delegatio= n is relatively small, that's a small set of numbers that have to have cert= s revoked and new ones issued. This is going to happen, a bunch of times, = until the SPs learn to handle their keys appropriately (probably by outsour= cing). But the scale of the problem introduced is small, and the fix is fa= irly simple to deploy. I propose not to "trust" SPs. We're going to issue certs matching number d= elegation and then check to make sure that the calls are signed with matchi= ng certs and keys. A pink SP can not issue certs and accept calls from its= customers unsigned. Hopefully, its peers will refuse its calls. The pink= SP can issue certs for numbers it is delegated without regard to how those= numbers are delegated by it. If the cops come calling, following the chai= n, they will arrive at the pink SP, who can then decide what it will do whe= n the "wrong" delegate was issued a cert and placed the call. The pink cer= t can hand its private key out. Same issue - the cops come to them followi= ng the chain. Wherever there is a compromise, we can follow the chain to s= ome entity that has not done the right thing. The regulator or LE may be a= ble to stop bad behavior, or the upstream entity might refuse calls from th= at SP, but only numbers delegated to that SP are open to abuse. A fortunat= e observation is that most of the pink SPs don't get a small number of rela= tively large delegations - they get a large number of relatively small dele= gations. This limits the size the problem introduced by a single key compr= omise. If the SP has a database of keys, and the database is compromised, = the problem is of course larger. This process does not match any existing model I think. It's not a "trust"= model in the classical sense, and it's not a reputation model, although it= has elements of both. The delegation (and certs) can continue right down to the end user. We don= 't trust them any more than we trust the SPs, but we can verify that they h= ave gotten the number through a chain of delegations. The chain could be c= ompromised, as above. Brian On Jun 11, 2013, at 10:25 AM, Dave Crocker wrote: > On 6/11/2013 5:58 AM, Rosen, Brian wrote: >> On Jun 10, 2013, at 7:50 PM, Dave Crocker wrote: >>>=20 >>> Glad to hear this. But of course it makes the trust model messier, >>> since you don't begin with trusted actors (like operators) >>> controlling things. >>>=20 >> Delegation is reasonably trustworthy - at least you can hold the >> delegator responsible. >=20 > I think I've heard different assertions of requirement on the list about = that. >=20 > What you cite here is 'accountability', which means the ability do to pos= t hoc (after the problem) followup. I've heard others cite 'prevention' as= the requirement, which means a pre hoc capability. >=20 > Of course, these are hugely different constraints, with that latter being= far more onerous, or at least technically and operationally demanding. >=20 >=20 >> The reason this is true is that there is a >> delegation from a number authority to a service provider that has >> some form of official recognition, and that entity has permission to >> enter calls into the PSTN. >=20 > This gets back to a question that has come up a few times: Does the trus= t model encompass -- or, at least, rely on -- only a relatively small numbe= r of specially-authorized operators, who are very highly vetted and account= able; or does it potentially encompass anyone with a SIP client? This is w= hy I've pressed for clarifying the statement and depiction about actors in = the STIR scenario. I think you suggest the answer a bit farther down, but = I wanted to call out the core question here. >=20 > If the requirement is to permit a calling SIP UA to assert the ID, then t= he set of participants is billions and accountability is an entirely differ= ent game. An intermediate place is a model of ID assertion by any "organiz= ation"; that is, anyone operating a SIP server along the path. It could sti= ll be far more unruly that limiting to a relatively tiny, regulated core, b= ut it's some orders of magnitude smaller than "everyone and every device". >=20 > Your note saying, "the notion of 'Service Provider' is broad. I'm not su= re we need a new term, but it's not equivalent to 'carrier'. It's any ind= ependent SIP or SS7 entity in the path." frankly appears to match the curre= nt email operational model... >=20 > (By way of comparison, DKIM's architectural model allows anyone along the= path to sign, including the author's UA; however the ID is a domain name, = which best scales to hosts and not users -- generally.) >=20 >=20 >> That means it is subject to about as >> much regulation as possible.If that entity delegates downward, the >> it can hold it's delegates to account, less it be left holding the >> bag. >=20 > This excludes a true peer-to-peer operation, without regulated service pr= oviders. I thought an earlier posting said the goal was to include P2P. >=20 >=20 >> Requiring the delegator to issue a cert is the new part. If >> the delegator doesn't handle it's private key securely, then a >> compromise of that part of the number space is possible, but it's >> limited to what it has been delegated. It would be better if the >> delegator contracted with an entity that was good at the job of being >> a CA, but we can't guarantee that will happen. >>=20 >>>=20 >>> And it means that there's potentially a key for each number. >> Yes, we're heading in that direction, primarily due to number portabilit= y. >=20 > dandy. >=20 >=20 >>> /And/ you want to allow signing by folk who don't 'own' the number. >> Well, the whole scheme is authority to sign is delegated. If an entity = that 'owns' the number authorizes someone else to use it, it would be a for= m of delegation. It would use it's key to issue a cert to the authorized e= ntity. In practice, that may be that the SP serving the end user is asked = to issue that cert by the end user. That looks like another level of deleg= ation, which is just fine. >=20 > OK. This defines a trust model comprising a core of regulated and highly = accountable operators that provide a base of assurance, but permitting dele= gation of trust down a hierarchy. That seems to be different than your sta= tement that I quoted, above. >=20 > However it does seem to match the current PSTN global model, but that it = excludes true P2P. >=20 >=20 >> Some believe we should have other forms of certs in the system. For exa= mple, someone proposed a "green carrier" cert that would work for all of ca= lls it originates. Others think that is not implementable (because it's to= o hard draw the line between a green carrier and a not-so-green one). Ther= e are other thoughts of giving certs to thinks like border elements who get= calls that are unsigned. They could sign them with a cert that was "I don= 't know what happened before me, but here is what I got for an identity, an= d I'll sign it so it can be checked from here forward. That probably wouldn= 't be all that useful for the problem at hand. >=20 > This moves the trust question from "assertion by fiat involving regulatio= n" to one of "reputation". Again, these impose vastly different design and= operation requirements. >=20 >=20 >>> FWIW, at a coarse, architectural level, what you are describing is quit= e similar to what DKIM confronts for email, including 'gatewaying' which in= the email case is represented by mailing list processing -- which is forma= lly a delivery to the list engine and a re-posting by it. (I did said 'coa= rse'.) For DKIM, the current view is that mailing lists need to re-sign th= e message; that would be an SS7>SIP gateway re-signing, here. But, of cour= se, it won't have the private key of the owner of the number=85 >> Yeah, sort of, if you squint hard enough. I don't think the analogy is = good enough though. DKIM doesn't have a real delegation model like this on= e. >=20 > It delegates name authentication, but not trust. DKIM doesn't assert tru= st, except for a signer's assertion of the name. Trust is an overlay mecha= nism, built up from the validation of the (domain) name use. >=20 > A detriment to that model is the need to then define the trust overlay. = The benefit of that model is that it allows exploring different instantiati= ons of the trust layer. Where trust is a complex topic, that's a win. It = might also be a necessity. >=20 > One concern is that efforts to create explicit 'trust' mechanisms over th= e global/public Internet has generally been highly problematic. Hence relia= nce on a model with a small, regulated core is appealing, but only if it re= ally is the required long-term model. As I've noted, I think some folk are= asserting expectations that seems to call that model into question. (For = this round, I'm not trying to express my own architectural preferences, but= merely get clarity on what's being said.) >=20 >=20 >>> Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than mai= ling lists, but from the traffic I've seen here, it doesn't sound reliable.= At a minimum, you might want to specify the core stuff without specifying= the SS7 relaying -- include it in the thinking but not the formal spec -- = and specify ss7 gatewaying separately. That's more than a documentation nu= ance. >> There is no doubt we need to get the basic mechanism done first. There = is wide agreement that there are two separate mechanisms, with separate doc= uments. >>>=20 >>> It makes for a /far/ simpler spec, because the core model is kept quite= simple. (I've always thought that, but watching the problems in the recent= EAI wg with this solidified the point for me.) >> We agree I believe >=20 > uh oh... >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Tue Jun 11 08:33: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 9394621F9A87 for ; Tue, 11 Jun 2013 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ezxzY8kfcmBC for ; Tue, 11 Jun 2013 08:33:26 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id AB8B921F9A82 for ; Tue, 11 Jun 2013 08:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370965284; x=1686321501; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=19WhTWwnvF MMzRii9H9bjmtV+gvTHqi8MgRHIsZVoh0=; b=eH8WpNidHkMNiGO70HlU0Y26ue k7mO2AgyTUI9iHNFOKZtTD92ctc2yvH8aDmSGChCRZxj1N3leJjYWpcTLygQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26100589; Tue, 11 Jun 2013 11:41:23 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 11:33:12 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 11:33:07 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvy4AgADR7ACAADY6gIAAFCKAgAANSgA= Date: Tue, 11 Jun 2013 15:33:06 +0000 Message-ID: <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> In-Reply-To: <51B7380D.1020706@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VQ/JBP9jgPJKJT0/E9j0Ug== Content-Type: text/plain; charset="us-ascii" Content-ID: <94DB553ED74E98419574E752E38DD398@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Dave Crocker , Dan York , "" , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 15:33:30 -0000 There certainly are people involved who want the result to stop MITM attack= s, but it's not the stated problem. I agree that the level of assurance for public keys needed is pretty modest= . See the reply I just sent to Dave. Telephone number assignment has been around for a century. It's built up a= lot of infrastructure, regulation, bureaucracy and custom. It has continu= ously evolved, and it's still evolving. But there are things that are stil= l hard to do. Public databases of information about telephone numbers is c= urrently a taboo. That may change. However, that's where we are today. = I really don't want to put changing that taboo in the way of succeeding. = Please? Brian On Jun 11, 2013, at 10:45 AM, Stephen Farrell w= rote: >=20 > Hi Brian, >=20 > So I didn't hear you say that the scheme outlined failed to > meet the use-cases other than in respect of the public key > retrieval aspect. That seems to imply that the role of any > CAs in a PKI here may differ a lot from e.g. TLS. Or to put > it another way, the level of assurance for public keys > needed may well be pretty modest, if the threat model does > not need to consider an on-path, MITM-type attacker. >=20 > I'm also confused as to why its a non-starter to have a > public database of public keys and phone numbers, but is ok > that anyone can build that database themselves, with fairly > modest effort. That seems odd to me anyway. (To be clear, > I do consider de-referencing a URL for a public key or > cert as a DB-lookup.) >=20 > My conclusion so far is that this effort should be quite > careful to not require a complex PKI if that's not really > needed. >=20 > S. >=20 > On 06/11/2013 02:33 PM, Rosen, Brian wrote: >> 1. Number delegation doesn't follow a tree. You can be delegated 25 num= bers in a range. We are rapidly evolving to a delegation of 1 number. The= tree than ENUM gives you doesn't match the delegation model, and thus the = cert model. You can force fit it by just expanding the whole tree out, but= that is inefficient and silly. We know how to do a simple web service que= ry with a telephone number and return an answer. Don't make things more co= mplicated. >> 2. The global root of the tree (e164.arpa) has been a nightmare >> 3. SIP Identity sends the URI of the cert in the signaling with the call= . You don't need a database to retrieve it. One of the proposed additiona= l mechanisms did need a way for the originator to discover the cert for the= termination. =20 >> 4. Unless there is some entity in a country that actually issues ALL the= certs, putting the certs in a publicly accessible database raises privacy = and business concerns that I (and a lot of other people) think are insurmou= ntable. You can't be able to tell which SP serves which numbers. That mig= ht change over time, but right now, it's impossible. I understand your obs= ervation about building up a DB of certs. I expect it to happen. But maki= ng the DB public today is a non-starter. =20 >>=20 >> Brian >>=20 >>=20 >> On Jun 11, 2013, at 6:19 AM, Stephen Farrell = wrote: >>=20 >>>=20 >>> So just following up on this to try to better understand >>> where it falls over... (there is a point to that, see the >>> end of this mail.) >>>=20 >>> For now, I'll stick with assuming public ENUM even if its >>> mythical since I think it has enough in common with any >>> public key retrieval mechanism for the current discussion. >>>=20 >>> On 06/10/2013 10:48 PM, Dan York wrote: >>>>=20 >>>> On 6/10/13 5:10 PM, "Stephen Farrell" wrot= e: >>>>=20 >>>>>> ENUM, as originally envisioned, was a public database. That is a >>>>>> complete non-starter. >>>>>=20 >>>>> Why? I mean for this application, not general phone numbers. >>>>>=20 >>>>> For this, I'd just want the signer's public key at the right >>>>> place in the DNS, where "right place" is maybe the delegation >>>>> point (sorry if that's the wrong term). Say if the caller's >>>>> phone is +353-1-896-1234 then the public key might be at >>>>> +353-1-896 in the DNS so my call from TCD to somewhere can >>>>> be signed by TCD. >>>>=20 >>>> So in this scenario, the signer might be the corporate PBX, with the b= ase >>>> phone number at +353-1-896? >>>>=20 >>>> How does the validating recipient system know to query for only that p= art >>>> of the phone number? Would it need to try for the full phone number >>>> first, then smaller parts of the number until it got back an answer? >>>> (This would seem to introduce latency and added DNS queries.) Or di= d I >>>> miss somewhere in the 100+ messages over the last few days a suggestio= n >>>> for a way to tie a part of a number to what to look up? >>>=20 >>> Speculating, let's say that the signed blob identifies the >>> signer by annotating the caller number, e.g. "+353-1-896/-1234" >>> where the "/" means that the signer is named in public ENUM >>> using the parts of the number to the left of the "/" i.e. in >>> this case that'd mean "+353-1-896" is the signer and I >>> should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar) >>> to find the public key. >>>=20 >>> Anyway, my question then is: with that setup and a sensible >>> signature format, why doesn't that work for the use-cases >>> that Brian enumerated? >>>=20 >>> If the only reason this fails is that it requires a publicly >>> accessible database that exposes the binding between keys and >>> sets of caller numbers, then I think any 5280-based solution >>> will have the same problem, even if that's less obvious. >>>=20 >>> For example, the SSL observatory [1] has built up an ~11million >>> entry DB of TLS server certs. That plus another ~4million >>> SSH host keys [2] were used to detect some badness in key >>> generation (probably from embedded devices with bad PRNGs). >>> For DKIM, I don't know that someone's built up such a DB, >>> but there'd be nothing much stopping anyone who sees a bunch >>> of email doing so if they wanted to. And we're even starting >>> to see benefits from such large databases of public keys, >>> e.g. RFC 6962 is one experimental spec for a way to use >>> such a beast to mitigate bad CA (diginotar-like) behaviour. >>>=20 >>> And similarly, for stir, anyone who takes a bunch of calls >>> (or instruments a UAC to send reports of certs to a central >>> place) could do the same. >>>=20 >>> So it seems to me that its just in the nature of public key >>> crypto that if you deploy this, then someone can build up >>> that DB of public-keys-or-certs vs. caller-numbers. Or if >>> you set a hard requirement to avoid that, then lots of new >>> work would be needed to develop a PKI that tries to make >>> that hard. >>>=20 >>> Cheers, >>> S. >>>=20 >>> [1] https://www.eff.org/observatory >>> [2] >>> https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-p= anic-over-factorable-keys-just-mind-your-ps-and-qs/ >>>=20 >>>>=20 >>>>> And again, I'm not advocating for such a thing, just asking >>>>> why its broken. >>>>=20 >>>> I'm sure someone like Brian or Richard Shockey could give you a long l= ist >>>> of reasons ENUM failed. A fundamental one to me is that a public ENUM >>>> database gave carriers and everyone access to all the meta information >>>> about what numbers were under a carrier's responsibility. And it prov= ided >>>> a wonderful way for spammers to walk the DNS tree and build up a nice = list >>>> of everyone to bombard with telemarketing calls. (And there are a coup= le >>>> of scripts out there that do exactly that.) >>>>=20 >>>> I realize you are not suggesting ENUM for the general case of phone >>>> numbers, but even in an abbreviated form I think it would probably exp= ose >>>> far more info publicly than most people are comfortable with. >>>>=20 >>>> My 2 cents, >>>> Dan >>>>=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 >>=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 richard@shockey.us Tue Jun 11 08: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 DE65621F8F6E for ; Tue, 11 Jun 2013 08:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.115, 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 pef2SlV3LBpX for ; Tue, 11 Jun 2013 08:58:20 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 702F621F8EEA for ; Tue, 11 Jun 2013 08:58:16 -0700 (PDT) Received: (qmail 12713 invoked by uid 0); 11 Jun 2013 15:57:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 11 Jun 2013 15:57:32 -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=KhI2iXFOAFo4AVXj67G/o5vGo5DuCQR+Lb/PiQesRUA=; b=Wk6QpDeYIGPBa+ZXtZBWtxpr4cJGo8OFb9gKe51knr4iXaRq5j7Nq0uO8HXz7i5qS6eggR3S57METCx6qfgJhNED5dtGLrtkliZP2QcRHND8zy5khzx+Gjbmv1vF7bhy; Received: from [72.66.111.124] (port=49341 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UmQwu-0007Xm-0Q; Tue, 11 Jun 2013 09:57:32 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Stephen Farrell'" References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <00ec01ce663b$8ab367c0$a01a3740$@shockey.us> <51B674DB.9060809@cs.tcd.ie> <1DA39C97-857B-4A1A-8265-E8E31A62DE1E@oracle.com> In-Reply-To: <1DA39C97-857B-4A1A-8265-E8E31A62DE1E@oracle.com> Date: Tue, 11 Jun 2013 11:57:28 -0400 Message-ID: <00e001ce66bc$60779ea0$2166dbe0$@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: AQKmG5pz++37aVJTb/vHdV/W8NbSYwHntOc5AjPy0gQBwyf+LAIYhVyTAaq0kXEB3hSFgAGpeArgAiMa3MQBND7N1AGA7t9bASUfhlMAaODz/ZbkwDYg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] clarity (was: Re: DKIM-like key mgmt approach) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 15:58:26 -0000 +1 exactly .. plus do remember we tried to extend the E2U model in ENUM to E2MD metadata at a couple of BOF's in 2010 and that got shredded pretty quickly. We know the limitations of ENUM and the DNS in general. I fully accept that. As Hadriel points out 6116 as a replacement for TCAP queries works wonders for the IMS/CSCF but so does SIP Redirect. Time it seems opens all old wounds. IMHO TERQ is a non starter here since the timelines for actually completing that idea will not rationally match any real world need. Maybe some time in the distant future it will not solve the immediate problem we are presented with. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, June 11, 2013 12:32 AM To: Stephen Farrell Cc: stir@ietf.org Subject: Re: [stir] clarity (was: Re: DKIM-like key mgmt approach) Well, it's a sensitive topic because in some ways and for some of us ENUM was a miserable failure, and for others a wild success. I don't know how much context/background you need though. I mean I don't know how much you don't already know, or what is useful to know. Some background on the current state of ENUM as I see it: As originally described/envisioned ENUM was just a usage of DNS, as you know... which from the IETF's perspective means 'The DNS', and thus not only the protocol but also the architecture and massive DNS deployment, query-able by any host on the Internet, etc. This is what most people call "Public ENUM". It was a miserable failure. However, as DNS the *protocol* for querying numbers and getting back URIs and other stuff for various purposes, ENUM is very successful. It's just that the "DNS" servers being queried for ENUM purposes are not in any way tied into 'The DNS', but are simply servers owned by the same service provider that owns the equipment performing the queries, and are not publicly reachable. That's 'Private ENUM'. It's only within Service Providers, not in Enterprises... think of it as the Service Provider's version of LDAP. There is also 'Carrier ENUM' which is pseudo-private, in the sense that the servers are still not part of The DNS and are only query-able from certain providers based on a federation or some form of common agreement/relationship. Carrier ENUM exists, but is not very successful afaik. Some background on using ENUM for Caller-ID verification: The topic has come up before, although I don't know if Rich or Brian remember it. It was discussed about 5 years ago, back when we had massive email threads about the many SIP Identity problems/solutions on the mailing lists. There were even some drafts about it... This one discussed the general problem area: http://tools.ietf.org/html/draft-schwartz-sip-e164-ownership-01 And this one discussed using ENUM/DNS for a PKI: http://tools.ietf.org/html/draft-darilion-sip-e164-enum-00 -hadriel On Jun 10, 2013, at 8:52 PM, Stephen Farrell wrote: > > FWIW - I have no idea how to interpret Rich's message and as a result > am also unsure how to interpret Brian's. > And that's about the 5th or 6th overly cryptic mail like that in the > last few days from various folks on this list. So this isn't really > aimed at either Brian or Rich but is a general plea for clarity. > > I'm sure there are a bunch of people on here who have all the context > for all this. But I'm not one of 'em. > And I bet I'm not alone. > > Assuming a homogeneous audience who all share the same painful history > is yet another way to bugger up a BoF in my experience. Just sayin. > > S. > > On 06/11/2013 01:35 AM, Richard Shockey wrote: >> Ah excuse me .. Why oh why does this come back to haunt me .. >> >> Like the Godfather III movie .. " once you think you are out, they >> pull you back in." >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Rosen, Brian >> Sent: Monday, June 10, 2013 4:47 PM >> To: Stephen Farrell >> Cc: stir@ietf.org; Dave Crocker; >> Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can >> canonical phone numbers survive SBCs and other middle boxes?) >> >> ENUM does not exist. >> [RS> ] >> [RS> ] It bloody well does exist.. not as e164.arpa but as private >> instantiations all over the place as well as a access protocol to >> Centralized Routing Databases internal to service provider networks. The IP >> SCP. SIP Redirect is currently preferred but the protocols are still built >> into the CSCF's. TCAP replacement.. duh let me know I can make up T-Shirts >> for Berlin .NO TCAP. NeuStar runs the I-TRS database for the hearing >> impaired for the FCC which is entirely based on 6116. Brian .don't go >> there. Yes your company runs a government sponsored private instantiation >> of 6116. Look it up people. >> >> We have an RFC, but we have essentially no deployment. >> >> ENUM, as originally envisioned, was a public database. That is a >> complete non-starter. >> [RS> ] >> [RS> ] In .arpa sure but the protocol is still in very active use. >> The ENUM WG declared success and I'm personally proud of that. Well >> now that you kindly bring up the subject. What if .. what if you did >> actually looked at reviving .e164.arpa but only as a tree for PKI and >> NO session establishment data? Well Hummmm maybe there is merit to >> that idea. The structural separation of PKI data from the underlying >> national numbering databases could offer some interesting >> alternatives. Worth thinking about. Worth discussing .. >> >> Granted I have some serious scars from the E2MD BOF's in 2010 but .. >> >> Well it might be worth a trial .. WOW. Gee I think I need to make a >> filing with the FCC as part of their DA 13-1016 filing. >> >> http://www.fcc.gov/document/technology-transitions-policy-task-force- >> seeks-c >> omment-trials >> >> Great Idea Brian thanks for the suggestion. What a guy!!! You are >> the best! >> >> >> >> ENUM tried to evolve to a private database, but in most places, it >> was not possible to organize the relationships to make it work. >> >> What works is number delegation, and centralized databases like the US NPAC. >> >> The proposed basic mechanism doesn't depend on a database of certs. >> The URL to the cert accompanies the signature. >> >> One of the proposed mechanisms for handling the so-called "out of band" >> mechanism that gets around SS7 links and SPs that don't preserve the >> signed information does depend on such a database. I think that is a weakness. >> There are ways to create such a database which do not depend on DNS. >> >> Brian >> On Jun 10, 2013, at 4:21 PM, Stephen Farrell >> >> wrote: >> >>> >>> Hi >>> >>> On 06/07/2013 08:17 PM, Dave Crocker wrote: >>>> (Just to be clear, I'm suggesting consideration of an approach; I'm >>>> not sure it's the best one and I'm therefore not pushing for its >>>> adoption, merely that it be explored.) >>>> >>>> Anyone can sign. They sign with a domain they own. So the >>>> signature goes with the operator, not with the content (number, >>>> message, >>>> whatever.) >>> >>> I'd also like to understand the argument here as to whether a DKIM >>> like approach to public key retrieval is good enough or not for this >>> application. (Note that this is orthogonal to any discussion about a >>> DKIM-like or 4474-like signature format, I'm just asking about >>> public key retrieval now.) >>> >>> As with everything, I don't need to understand it now, but I do >>> think that a bunch of folks here are making assumptions about PKI >>> that might turn out to be a large amount of work later, e.g. that TN >>> delegation specific certificate chains exist, can be found and can >>> be verified efficiently. >>> >>> One could easily argue that since ENUM exists and DKIM key records >>> exist (*) a DNS lookup could be the way to get signers' public keys >>> without requiring any 5280 processing at all at the signer or verifier. >>> >>> One could further argue that that'd be sufficiently "secure" even >>> without DNSSEC, in that it'd be enough to mitigate your robocaller >>> issues on the basis that those robocallers aren't gonna MITM or >>> poison DNS at the verifier. >>> >>> A similar argument was made for DKIM: since a bad DKIM signature is >>> the same as no signature on a mail message, there's no need to >>> require DNSSEC to get DKIM started. >>> >>> While its not quite the same in this context, it may be that one >>> could argue that a reasonable threat model would not require the >>> signature verifier (someone/thing en-route to the callee) to >>> strongly verify the signing public key. >>> >>> (Ok, I can't resist adding a feature:-) If the DKIM key selector >>> were modified (to put it in the key value) then you might also get >>> some level of traceability in that one could trawl the DNS for >>> signer's public keys. I don't know if that'd be good or bad. >>> >>> Anyway, for now, can we make sure this gets discussed before we >>> plump for any specific key management solution? That could be now, >>> or at a DISPATCH session or BoF or after a WG is chartered, I don't >>> mind, so long as it is properly considered. >>> >>> S. >>> >>> (*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing. >>> For the present discussion, just assume that the keys are in the >>> "correct" kind of RR. >>> >> >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Tue Jun 11 09:07: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 049D721F93E1 for ; Tue, 11 Jun 2013 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 nIzkfMsTDQsY for ; Tue, 11 Jun 2013 09:06:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A078321F91AB for ; Tue, 11 Jun 2013 09:06:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF241BE8B; Tue, 11 Jun 2013 17:06:34 +0100 (IST) 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 hpHohWf1sq44; Tue, 11 Jun 2013 17:06:34 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c] (unknown [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3D0DBE75; Tue, 11 Jun 2013 17:06:34 +0100 (IST) Message-ID: <51B74B0B.5080606@cs.tcd.ie> Date: Tue, 11 Jun 2013 17:06:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> In-Reply-To: <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , Dan York , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 16:07:03 -0000 On 06/11/2013 04:33 PM, Rosen, Brian wrote: > There certainly are people involved who want the result to stop MITM attacks, but it's not the stated problem. Right. I think the putative wg will need to be clear about that. That is, a threat-model is needed. (Bet you knew I'd say that:-) > I agree that the level of assurance for public keys needed is pretty modest. See the reply I just sent to Dave. Good. That's an important point. I have to say though that your response to Dave makes a fair few assumptions about how to design the system - it basically reads like a phone number analog to the RPKI. (And that's fine - this work does need people proposing stuff after all.) Now that could work I would guess, but it does bring a lot of complexity. And I'm questioning whether all that's needed, for the modest level of assurance required. > Telephone number assignment has been around for a century. It's built up a lot of infrastructure, regulation, bureaucracy and custom. It has continuously evolved, and it's still evolving. But there are things that are still hard to do. Public databases of information about telephone numbers is currently a taboo. That may change. However, that's where we are today. I really don't want to put changing that taboo in the way of succeeding. Please? I do get the privacy concerns. And those need to be avoided or addressed. But its not clear to me that an RPKI analog would do that though, e.g. OCSP requests may well be needed (or else no revocation) since I'm guessing it'd be unlikely that pre-cooked OCSP responses or small CRLs could be stapled to the SIP messages. And in the browser world those OCSP transactions are both slow and privacy unfriendly. And as I said, any PKI is liable to allow anyone to build a reasonable version of the public-key/phone#-delegation DB. Again, all of this needs working out, but it'd not be right to start that from a position that the RPKI analog is the solution IMO. It may turn out that way, or maybe it won't. S. PS: Just to be crystal clear - I'm not advocating for any particular approach here. Mostly I' want to try help make sure that what gets done here is deployable - I've wasted too much of my own and other people's time over the years on security stuff that didn't get used;-) > Brian > > > On Jun 11, 2013, at 10:45 AM, Stephen Farrell wrote: > >> >> Hi Brian, >> >> So I didn't hear you say that the scheme outlined failed to >> meet the use-cases other than in respect of the public key >> retrieval aspect. That seems to imply that the role of any >> CAs in a PKI here may differ a lot from e.g. TLS. Or to put >> it another way, the level of assurance for public keys >> needed may well be pretty modest, if the threat model does >> not need to consider an on-path, MITM-type attacker. >> >> I'm also confused as to why its a non-starter to have a >> public database of public keys and phone numbers, but is ok >> that anyone can build that database themselves, with fairly >> modest effort. That seems odd to me anyway. (To be clear, >> I do consider de-referencing a URL for a public key or >> cert as a DB-lookup.) >> >> My conclusion so far is that this effort should be quite >> careful to not require a complex PKI if that's not really >> needed. >> >> S. >> >> On 06/11/2013 02:33 PM, Rosen, Brian wrote: >>> 1. Number delegation doesn't follow a tree. You can be delegated 25 numbers in a range. We are rapidly evolving to a delegation of 1 number. The tree than ENUM gives you doesn't match the delegation model, and thus the cert model. You can force fit it by just expanding the whole tree out, but that is inefficient and silly. We know how to do a simple web service query with a telephone number and return an answer. Don't make things more complicated. >>> 2. The global root of the tree (e164.arpa) has been a nightmare >>> 3. SIP Identity sends the URI of the cert in the signaling with the call. You don't need a database to retrieve it. One of the proposed additional mechanisms did need a way for the originator to discover the cert for the termination. >>> 4. Unless there is some entity in a country that actually issues ALL the certs, putting the certs in a publicly accessible database raises privacy and business concerns that I (and a lot of other people) think are insurmountable. You can't be able to tell which SP serves which numbers. That might change over time, but right now, it's impossible. I understand your observation about building up a DB of certs. I expect it to happen. But making the DB public today is a non-starter. >>> >>> Brian >>> >>> >>> On Jun 11, 2013, at 6:19 AM, Stephen Farrell wrote: >>> >>>> >>>> So just following up on this to try to better understand >>>> where it falls over... (there is a point to that, see the >>>> end of this mail.) >>>> >>>> For now, I'll stick with assuming public ENUM even if its >>>> mythical since I think it has enough in common with any >>>> public key retrieval mechanism for the current discussion. >>>> >>>> On 06/10/2013 10:48 PM, Dan York wrote: >>>>> >>>>> On 6/10/13 5:10 PM, "Stephen Farrell" wrote: >>>>> >>>>>>> ENUM, as originally envisioned, was a public database. That is a >>>>>>> complete non-starter. >>>>>> >>>>>> Why? I mean for this application, not general phone numbers. >>>>>> >>>>>> For this, I'd just want the signer's public key at the right >>>>>> place in the DNS, where "right place" is maybe the delegation >>>>>> point (sorry if that's the wrong term). Say if the caller's >>>>>> phone is +353-1-896-1234 then the public key might be at >>>>>> +353-1-896 in the DNS so my call from TCD to somewhere can >>>>>> be signed by TCD. >>>>> >>>>> So in this scenario, the signer might be the corporate PBX, with the base >>>>> phone number at +353-1-896? >>>>> >>>>> How does the validating recipient system know to query for only that part >>>>> of the phone number? Would it need to try for the full phone number >>>>> first, then smaller parts of the number until it got back an answer? >>>>> (This would seem to introduce latency and added DNS queries.) Or did I >>>>> miss somewhere in the 100+ messages over the last few days a suggestion >>>>> for a way to tie a part of a number to what to look up? >>>> >>>> Speculating, let's say that the signed blob identifies the >>>> signer by annotating the caller number, e.g. "+353-1-896/-1234" >>>> where the "/" means that the signer is named in public ENUM >>>> using the parts of the number to the left of the "/" i.e. in >>>> this case that'd mean "+353-1-896" is the signer and I >>>> should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar) >>>> to find the public key. >>>> >>>> Anyway, my question then is: with that setup and a sensible >>>> signature format, why doesn't that work for the use-cases >>>> that Brian enumerated? >>>> >>>> If the only reason this fails is that it requires a publicly >>>> accessible database that exposes the binding between keys and >>>> sets of caller numbers, then I think any 5280-based solution >>>> will have the same problem, even if that's less obvious. >>>> >>>> For example, the SSL observatory [1] has built up an ~11million >>>> entry DB of TLS server certs. That plus another ~4million >>>> SSH host keys [2] were used to detect some badness in key >>>> generation (probably from embedded devices with bad PRNGs). >>>> For DKIM, I don't know that someone's built up such a DB, >>>> but there'd be nothing much stopping anyone who sees a bunch >>>> of email doing so if they wanted to. And we're even starting >>>> to see benefits from such large databases of public keys, >>>> e.g. RFC 6962 is one experimental spec for a way to use >>>> such a beast to mitigate bad CA (diginotar-like) behaviour. >>>> >>>> And similarly, for stir, anyone who takes a bunch of calls >>>> (or instruments a UAC to send reports of certs to a central >>>> place) could do the same. >>>> >>>> So it seems to me that its just in the nature of public key >>>> crypto that if you deploy this, then someone can build up >>>> that DB of public-keys-or-certs vs. caller-numbers. Or if >>>> you set a hard requirement to avoid that, then lots of new >>>> work would be needed to develop a PKI that tries to make >>>> that hard. >>>> >>>> Cheers, >>>> S. >>>> >>>> [1] https://www.eff.org/observatory >>>> [2] >>>> https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/ >>>> >>>>> >>>>>> And again, I'm not advocating for such a thing, just asking >>>>>> why its broken. >>>>> >>>>> I'm sure someone like Brian or Richard Shockey could give you a long list >>>>> of reasons ENUM failed. A fundamental one to me is that a public ENUM >>>>> database gave carriers and everyone access to all the meta information >>>>> about what numbers were under a carrier's responsibility. And it provided >>>>> a wonderful way for spammers to walk the DNS tree and build up a nice list >>>>> of everyone to bombard with telemarketing calls. (And there are a couple >>>>> of scripts out there that do exactly that.) >>>>> >>>>> I realize you are not suggesting ENUM for the general case of phone >>>>> numbers, but even in an abbreviated form I think it would probably expose >>>>> far more info publicly than most people are comfortable with. >>>>> >>>>> My 2 cents, >>>>> Dan >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 dhc2@dcrocker.net Tue Jun 11 09:12: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 D5E1621F960F for ; Tue, 11 Jun 2013 09:12:43 -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 t2N1rTHA+iDg for ; Tue, 11 Jun 2013 09:12:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D62BD21F962D for ; Tue, 11 Jun 2013 09:12:35 -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 r5BGCPbh018070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 09:12:28 -0700 Message-ID: <51B74C64.4070302@dcrocker.net> Date: Tue, 11 Jun 2013 09:12:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> <02A4880B-8DBE-48D8-A5EC-DD82EC282527@neustar.biz> In-Reply-To: <02A4880B-8DBE-48D8-A5EC-DD82EC282527@neustar.biz> 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, 11 Jun 2013 09:12:29 -0700 (PDT) Cc: "hadriel.kaplan@oracle.com" , Michael Hammer , "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] Permitted spoofing 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, 11 Jun 2013 16:12:44 -0000 On 6/11/2013 6:03 AM, Rosen, Brian wrote: > MITM is a potential problem, which would be desirable to cut off, but it's not the stated problem we're trying to solve. > > There may be some number of service providers in the path that are tolerant of the problem, but not really complicit. This could have a pretty substantial effect on design choices. For example, session-based SSL authentication -- that is, without server validation (certs) -- permits MITM, which seems to be often/generally acceptable in terms of actual practice, although rhetoric claims otherwise. But in general, I've had the impression that any effort at authentication or confidentiality comes with an expectation of resistance to MITM compromises. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Tue Jun 11 09:19: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 E1C9D21F8904 for ; Tue, 11 Jun 2013 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 K4na5LJSB88i for ; Tue, 11 Jun 2013 09:19:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AF91121F88FB for ; Tue, 11 Jun 2013 09:19:15 -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 r5BGIxAs013862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 16:19:00 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 r5BGJ1Zu004079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 16:19:01 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5BGJ086015448; Tue, 11 Jun 2013 16:19:00 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2013 09:19:00 -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, 11 Jun 2013 12:18:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <808264A5-46B4-4244-9479-5EA445C326F4@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B640D5.4000406@cs.tcd.ie> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , Dave Crocker , "" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 16:19:23 -0000 On Jun 10, 2013, at 5:40 PM, "Rosen, Brian" = wrote: > ENUM depended on several things that turned out to be very hard to = arrange: > 1. The global root problem. Using the ITU was problematic, but having = said that, there isn't any other obvious answer either > 2. Carrier cooperation. Hasn't happened. > 3. Regulator pressure. Hasn't happened. Actually the opposite - the = regulator had to ask the ITU to delegate the country code. Never = happened. I think the above is going to be true of anything we do: either the = carriers and regulators and so on all cooperate for a given country, or = we won't succeed. I'm not even sure the above was really the problem for Public ENUM... = more like the symptom not the cause. The cause, imho, was that Public = ENUM had no benefit for the stakeholders. Imagine if every E.164 number = was in The DNS. So what? You couldn't actually make a call directly to = anyone, because people don't just blindly accept SIP requests directly = from anyone on the public Internet. And even if people suddenly went = nuts and started wanting to, why would the Service Providers want to, or = even the regulators want to? But anyway... one real downside with having a Public ENUM for a PKI is = that you could learn most or every number of an Enterprise or Service = Provider by just iterating the numbers. Even if the record reveals = nothing personal, you'll know which numbers belong to which = company/organization. It's kinda like the concern people have with = DNSSEC and the NSEC response, but much worse because an NSEC3-type thing = won't help since the possible permutations of numbers are finite. -hadriel From dhc2@dcrocker.net Tue Jun 11 09:23: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 6F7A121F9711 for ; Tue, 11 Jun 2013 09:23:27 -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 03vtNHffkVwN for ; Tue, 11 Jun 2013 09:23:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBF21F96DF for ; Tue, 11 Jun 2013 09:23:17 -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 r5BGN75o018417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 09:23:10 -0700 Message-ID: <51B74EE6.2090103@dcrocker.net> Date: Tue, 11 Jun 2013 09:23:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B640D5.4000406@cs.tcd.ie> <808264A5-46B4-4244-9479-5EA445C326F4@oracle.com> In-Reply-To: <808264A5-46B4-4244-9479-5EA445C326F4@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 11 Jun 2013 09:23:11 -0700 (PDT) Cc: "Rosen, Brian" , "" , "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach 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, 11 Jun 2013 16:23:31 -0000 On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: > But anyway... one real downside with having a Public ENUM for a PKI is that you could learn most or every number of an Enterprise or Service Provider by just iterating the numbers. Even if the record reveals nothing personal, you'll know which numbers belong to which company/organization. if the target model is true end-to-end validation of number use, that problem is going to be present, independent of the technical solution. the only way to avoid that problem is to require that queries only be among a trusted, regulated core. and from postings over the last couple of days, it sounds as if that's /not/ the goal. (and irrelevantly i'll add that i'm glad...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Tue Jun 11 09:42: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 5416B21F93F8 for ; Tue, 11 Jun 2013 09:42:32 -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 YV+plMWa-QbI for ; Tue, 11 Jun 2013 09:42:28 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E5F2621F941D for ; Tue, 11 Jun 2013 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370968827; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=JtIMbho8oD Edhz0Nb6AUM+LjPfKvqsoxcipMAO/8z4Q=; b=S9dRuPrvt1jOBq6xF1D+MwQHa8 7KIIAdoz7e5r06j4UI7sR4V9zDfo1bavmEl68g7B9FvCQ3PfUANzF5UN68JA== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19400688; Tue, 11 Jun 2013 12:40:25 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 12:42:11 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 12:42:10 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvy4AgADR7ACAADY6gIAAFCKAgAANSgCAAAlagIAACe6A Date: Tue, 11 Jun 2013 16:42:09 +0000 Message-ID: <853E887A-4498-4E56-A9CB-9A6CB7F926EF@neustar.biz> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> <51B74B0B.5080606@cs.tcd.ie> In-Reply-To: <51B74B0B.5080606@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Ui9hsQmMRQtARe/jV1UvQQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8D71D547079C914ABF4DCD9F040BD69F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker , Dan York , "" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 16:42:32 -0000 On Jun 11, 2013, at 12:06 PM, Stephen Farrell wrote: >=20 >=20 > On 06/11/2013 04:33 PM, Rosen, Brian wrote: >> There certainly are people involved who want the result to stop MITM att= acks, but it's not the stated problem. >=20 > Right. I think the putative wg will need to be clear about that. > That is, a threat-model is needed. (Bet you knew I'd say that:-) >=20 >> I agree that the level of assurance for public keys needed is pretty mod= est. See the reply I just sent to Dave. >=20 > Good. That's an important point. >=20 > I have to say though that your response to Dave makes a fair > few assumptions about how to design the system - it basically > reads like a phone number analog to the RPKI. (And that's > fine - this work does need people proposing stuff after all.) > Now that could work I would guess, but it does bring a lot of > complexity. And I'm questioning whether all that's needed, > for the modest level of assurance required. There might be another model that would work, but I haven't heard it yet. >=20 >> Telephone number assignment has been around for a century. It's built u= p a lot of infrastructure, regulation, bureaucracy and custom. It has cont= inuously evolved, and it's still evolving. But there are things that are s= till hard to do. Public databases of information about telephone numbers i= s currently a taboo. That may change. However, that's where we are today.= I really don't want to put changing that taboo in the way of succeeding= . Please? >=20 > I do get the privacy concerns. And those need to be avoided > or addressed. But its not clear to me that an RPKI analog > would do that though, e.g. OCSP requests may well be needed > (or else no revocation) since I'm guessing it'd be unlikely > that pre-cooked OCSP responses or small CRLs could be stapled > to the SIP messages. We definitely need OCSP or something really similar. Note that when you get a delegation for a range, in many countries that ran= ge is subject to porting. And that means a specific TN in the range may no= t be valid for the range. That's different from revoking a certificate for= the range, but it could be done with one mechanism - is the cert for the r= ange valid, and is the number still in the range? We would not want to rev= oke the cert and issue several smaller ones leaving out the ported-out numb= er. "Porting out" has a complication. The national porting mechanism has desig= nated players, usually some form of carrier today, but that is evolving. B= ut the official porting database has the routing information among the "car= riers" that participate. Delegation involves those parties, but it also ma= y have several levels of provider who are not participants in the national = porting scheme. Let me use an example: Suppose Alice Carrier has two resellers, Bob and Charlie. Bob and Charlie = each have customers. If a customer of Bob ports in a number from some othe= r carrier other than Alice, then Alice has to complete the port in the nati= onal database on behalf of Bob. =20 But suppose Bob ports a number in from Charlie? From the national database= s' point of view, there is no port, Alice is the SP of record before and af= ter. However, from Bob and Charlie's point of view, this is a port like an= y other port. Alice has to make bookkeeping adjustments, and has to issue = a cert for the ported in number to Bob. Depending on how Charlie got the n= umber before it ported to Bob, Alice may have to tell anyone that the cert = it issued to Charlie for the number range is invalid for the number that wa= s ported to Bob. So, Alice needs to answer a query similar to that described above - it's no= t limited to the national porting database. Brian > And in the browser world those OCSP > transactions are both slow and privacy unfriendly. And as > I said, any PKI is liable to allow anyone to build a > reasonable version of the public-key/phone#-delegation DB. There is a trade-off in how much work an SP wants to do itself, and what th= at reveals to other parties. I think it will be common for one or more ent= ities to provide an outsourcing service for the sub delegations. That might= be used to regain some of the privacy that would be lost if the SP did the= work itself. >=20 > Again, all of this needs working out, but it'd not be right > to start that from a position that the RPKI analog is the > solution IMO. It may turn out that way, or maybe it won't. It's close, but not the same. Delegation doesn't work the same (not powers= of 2 for example). Different trust assumptions. But "certs follow delega= tion" is similar. >=20 > S. >=20 > PS: Just to be crystal clear - I'm not advocating for any > particular approach here. Mostly I' want to try help make > sure that what gets done here is deployable - I've wasted > too much of my own and other people's time over the years > on security stuff that didn't get used;-) Same here. I know some stuff about what is deployable and what is not isn'= t exactly rational, but we do have a bunch of experience that we're trying = to leverage. Brian= From hadriel.kaplan@oracle.com Tue Jun 11 09:55: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 11A1C21F95EF for ; Tue, 11 Jun 2013 09:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 NEgdpVg0Labs for ; Tue, 11 Jun 2013 09:55:12 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0632F21F9412 for ; Tue, 11 Jun 2013 09:55:04 -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 r5BGsmr8027453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 16:54:49 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 r5BGslBA011791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 16:54:48 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 r5BGsl2g008638; Tue, 11 Jun 2013 16:54:47 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2013 09:54: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: <51B7380D.1020706@cs.tcd.ie> Date: Tue, 11 Jun 2013 12:54:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Rosen, Brian" , Dave Crocker , Dan York , "" , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 16:55:17 -0000 On Jun 11, 2013, at 10:45 AM, Stephen Farrell = wrote: > I'm also confused as to why its a non-starter to have a > public database of public keys and phone numbers, but is ok > that anyone can build that database themselves, with fairly > modest effort. That seems odd to me anyway. (To be clear, > I do consider de-referencing a URL for a public key or > cert as a DB-lookup.) If the mechanism uses a URL for de-referencing, then the structure of = the URL does not need to follow phone numbers in any way. So you = couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I = sign it and in the SIP INVITE I tell you to go get the cert from: http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb The cert you download says it's for "+1-212-555-1212" (e.g., in the SAN = field or something), and it's issuer is NANPA (North American Numbering = Plan Administration), which you presumably have locally known root cert = for and acceptance as a trusted CA. So yes if you received the call from +1-212-555-1212 you'd know it's an = AT&T number (because of the URL's domain), but you wouldn't be able to = figure out what other numbers AT&T has - only those that called you. Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" follows a = schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org". You don't = even need to receive a call. Just start querying all possible digits of = the fixed length/depth. For the 212 area code there are only 10 million = possible numbers. Even for all of the US it's only around a couple = billion, because most area codes haven't been allocated, and the list of = which ones have is public: = http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_co= des -hadriel p.s. the above is not to say I think using HTTP is the right answer - = you can do the same thing with other database query protocols. The = point is the query key need not follow any number-based or well-known = schema. From stephen.farrell@cs.tcd.ie Tue Jun 11 10:03: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 C3AD021F96EB for ; Tue, 11 Jun 2013 10:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 7-ssC9XljnLW for ; Tue, 11 Jun 2013 10:03:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB021F96F5 for ; Tue, 11 Jun 2013 10:03:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2A9E4BE8A; Tue, 11 Jun 2013 18:02:53 +0100 (IST) 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 ieD0LjHgsVVn; Tue, 11 Jun 2013 18:02:53 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c] (unknown [IPv6:2001:770:10:203:4c4a:5178:e3e0:222c]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 01BB2BE83; Tue, 11 Jun 2013 18:02:53 +0100 (IST) Message-ID: <51B7583D.5020105@cs.tcd.ie> Date: Tue, 11 Jun 2013 18:02:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> In-Reply-To: <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , Dave Crocker , Dan York , "" , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 17:03:26 -0000 On 06/11/2013 05:54 PM, Hadriel Kaplan wrote: > If the mechanism uses a URL for de-referencing, then the structure of the URL does not need to follow phone numbers in any way. So you couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I sign it and in the SIP INVITE I tell you to go get the cert from: > > http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb > > The cert you download says it's for "+1-212-555-1212" (e.g., in the SAN field or something), and it's issuer is NANPA (North American Numbering Plan Administration), which you presumably have locally known root cert for and acceptance as a trusted CA. Sure. I then send the cert to EFF and they add it to the SSL observatory data set. Soon they'll have the mapping for most keys to/from most phone numbers. Yes, that'll get out of date if they don't keep up, but the relationships that one can infer from that data set is the only reason to not make it all public in the first place. I agree that a public ENUM thing would be easier to walk. DKIM has selectors in the DNS names and you only get those from email headers so DKIM is about the same as an RPKI analog in this respect if the selectors and URLs are equally unpredictable. S. From hgs@cs.columbia.edu Tue Jun 11 11:32: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 98FB021F9942 for ; Tue, 11 Jun 2013 11:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 PQVx+i2SUlVS for ; Tue, 11 Jun 2013 11:32:47 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1955C21F993E for ; Tue, 11 Jun 2013 11:32:47 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5BIWYQl022635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jun 2013 14:32:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <51B74EE6.2090103@dcrocker.net> Date: Tue, 11 Jun 2013 14:32:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B640D5.4000406@cs.tcd.ie> <808264A5-46B4-4244-9479-5EA445C326F4@oracle.com> <51B74EE6.2090103@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: "Rosen, Brian" , Stephen Farrell , Hadriel Kaplan , "stir@ietf.org" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 18:32:51 -0000 I suspect access rules, both technical and legal, to any databases may = vary among countries. If the database stores public key - number pairs, = there is no particular need for an organization just to have one public = key, if it doesn't want to provide clues to its holdings.=20 In general, for service providers, the assignment of numbers isn't = public, but it isn't a deep secret, either, at least among the entities = that likely have some competitive interest in this. The LERG contains = this information today, for example. On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: > On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >> But anyway... one real downside with having a Public ENUM for a PKI = is that you could learn most or every number of an Enterprise or Service = Provider by just iterating the numbers. Even if the record reveals = nothing personal, you'll know which numbers belong to which = company/organization. >=20 >=20 > if the target model is true end-to-end validation of number use, that = problem is going to be present, independent of the technical solution. >=20 > the only way to avoid that problem is to require that queries only be = among a trusted, regulated core. and from postings over the last couple = of days, it sounds as if that's /not/ the goal. (and irrelevantly i'll = add that i'm glad...) >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From hgs@cs.columbia.edu Tue Jun 11 11:48: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 8FCBF21F9992 for ; Tue, 11 Jun 2013 11:48:23 -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, NORMAL_HTTP_TO_IP=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 HyVX6coNCCDt for ; Tue, 11 Jun 2013 11:48:19 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4928921F994C for ; Tue, 11 Jun 2013 11:48:19 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5BImHei000693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jun 2013 14:48:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> Date: Tue, 11 Jun 2013 14:48:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 18:48:23 -0000 As a side note, there is no particular need to store the mapping in = carrier-specific database. Today, databases are operated by various = third parties (NeutralTandem and kin, Neustar, obviously), so there's = plenty of opportunity to obscure this information, if desired. On Jun 11, 2013, at 12:54 PM, Hadriel Kaplan wrote: >=20 > On Jun 11, 2013, at 10:45 AM, Stephen Farrell = wrote: >=20 >> I'm also confused as to why its a non-starter to have a >> public database of public keys and phone numbers, but is ok >> that anyone can build that database themselves, with fairly >> modest effort. That seems odd to me anyway. (To be clear, >> I do consider de-referencing a URL for a public key or >> cert as a DB-lookup.) >=20 > If the mechanism uses a URL for de-referencing, then the structure of = the URL does not need to follow phone numbers in any way. So you = couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I = sign it and in the SIP INVITE I tell you to go get the cert from: >=20 > http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb >=20 > The cert you download says it's for "+1-212-555-1212" (e.g., in the = SAN field or something), and it's issuer is NANPA (North American = Numbering Plan Administration), which you presumably have locally known = root cert for and acceptance as a trusted CA. >=20 > So yes if you received the call from +1-212-555-1212 you'd know it's = an AT&T number (because of the URL's domain), but you wouldn't be able = to figure out what other numbers AT&T has - only those that called you. >=20 > Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" follows = a schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org". You don't = even need to receive a call. Just start querying all possible digits of = the fixed length/depth. For the 212 area code there are only 10 million = possible numbers. Even for all of the US it's only around a couple = billion, because most area codes haven't been allocated, and the list of = which ones have is public: > = http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_co= des >=20 > -hadriel > p.s. the above is not to say I think using HTTP is the right answer - = you can do the same thing with other database query protocols. The = point is the query key need not follow any number-based or well-known = schema. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From dhc2@dcrocker.net Tue Jun 11 11:48: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 346CC21F99A0 for ; Tue, 11 Jun 2013 11:48: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 e++9InwcnbTb for ; Tue, 11 Jun 2013 11:48:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8421F99A1 for ; Tue, 11 Jun 2013 11:48: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 r5BImLKC021386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 11:48:24 -0700 Message-ID: <51B770EF.8020009@dcrocker.net> Date: Tue, 11 Jun 2013 11:48:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> <51B74B0B.5080606@cs.tcd.ie> <853E887A-4498-4E56-A9CB-9A6CB7F926EF@neustar.biz> In-Reply-To: <853E887A-4498-4E56-A9CB-9A6CB7F926EF@neustar.biz> 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, 11 Jun 2013 11:48:24 -0700 (PDT) Cc: "stir@ietf.org" , Dan York , "" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach 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, 11 Jun 2013 18:48:34 -0000 On 6/11/2013 9:42 AM, Rosen, Brian wrote: > There might be another model that would work, but I haven't heard it yet. Brian, Forgive me, but we haven't actually heard the one that you are working from, either. We've heard bits about it, but no summary explication that can be compared against alternatives. It's clear that you and some others are indeed working from a solid sense of a system architecture here, but the rest of us are left guessing. Consequently, bits are getting elucidated piecemeal, causing fragmentation and possibly misunderstandings to the discussion about it. I'm not talking about a detailed spec. A common diagram style like I did earlier -- except specific to the proposal you have -- and summary of the interactions and exchanged objects would go a long way. As I say, you've already offered bit of it; it's the integrated summary that's missing. d/ ps. also wanted to thank your for: > On 6/11/2013 8:13 AM, Rosen, Brian wrote:> Our GOAL is to have valid identity put on the call at the outset, and at least potentially verifiable all along the path. The GOAL is end to end verifiability. which is quite helpful. -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Tue Jun 11 12:10: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 867A221F8ECB for ; Tue, 11 Jun 2013 12:10:44 -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 4OgyHw48h79P for ; Tue, 11 Jun 2013 12:10:40 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCFA21F8F9E for ; Tue, 11 Jun 2013 12:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370978010; x=1686337386; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=5gxOSoXS76 MqWIU9Fk08N/U+M+Glb1eishQx40fDLA0=; b=S8zbWN+Jx3mh5C1PLpk3M8Svnv 3ozAZhVu3pCSLgyRHIRlDuqTcoF2bS0wxiO1cNeRK3Ejb3XHdXzeMXPNkUCw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24955474; Tue, 11 Jun 2013 15:13:29 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 15:10:27 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 15:10:24 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvy4AgADR7ACAADY6gIAAFCKAgAANSgCAAAlagIAACe6AgAAjPoCAAAYuAA== Date: Tue, 11 Jun 2013 19:10:23 +0000 Message-ID: References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <3F0E5D4B-1DEA-45A5-A0B1-BDFDB7DD1879@neustar.biz> <51B74B0B.5080606@cs.tcd.ie> <853E887A-4498-4E56-A9CB-9A6CB7F926EF@neustar.biz> <51B770EF.8020009@dcrocker.net> In-Reply-To: <51B770EF.8020009@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: kQFIPd0xMhCs0v/T3HgJBQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <198FF95C19B4054E910CA4B6FFACB442@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dan York , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:10:44 -0000 I think I've said it a couple of times: PKI based on number delegation, rooted in the national number authority. C= erts follow delegation. If you have the number, you get a cert to sign wit= h. There is a SIP Identity-like header with a signature over the canonicalized= To, From, timestamp and some kind of call id like the INSIPID id. =20 There is a SIP Identity Info-like header with a URL to the cert that was us= ed to create the signature. A caller or SP serving the caller extracts the canonical To/From/timestamp/= Call Id from the SIP header, computes the signature and adds the headers to= the call. Any SP or the endpoint validates by fetching the cert, validating it, extra= cting the info, and verifying the signature. Validating the cert includes= making sure the cert is still valid for the range. There is some other mechanism that helps when the signature or the info use= d to compute the signature, is mangled in the path. There is also a hash of the media description (SDP) included in the header = and covered by the signature. The media hash wouldn't validate for most ca= lls today, but some day, if media wasn't anchored somewhere other than the = endpoints, as it usually is today, you could tell if the media had been hij= acked. The signature would work if the SDP was altered, but verifying the = hash would fail. Brian On Jun 11, 2013, at 2:48 PM, Dave Crocker wrote: > On 6/11/2013 9:42 AM, Rosen, Brian wrote: >> There might be another model that would work, but I haven't heard it yet= . >=20 >=20 > Brian, >=20 > Forgive me, but we haven't actually heard the one that you are working fr= om, either. >=20 > We've heard bits about it, but no summary explication that can be compare= d against alternatives. >=20 > It's clear that you and some others are indeed working from a solid sense= of a system architecture here, but the rest of us are left guessing. Cons= equently, bits are getting elucidated piecemeal, causing fragmentation and = possibly misunderstandings to the discussion about it. >=20 > I'm not talking about a detailed spec. A common diagram style like I did= earlier -- except specific to the proposal you have -- and summary of the = interactions and exchanged objects would go a long way. As I say, you've a= lready offered bit of it; it's the integrated summary that's missing. >=20 >=20 > d/ >=20 >=20 > ps. also wanted to thank your for: >=20 >> On 6/11/2013 8:13 AM, Rosen, Brian wrote:> Our GOAL is to have valid ide= ntity put on the call at the outset, and at least potentially verifiable al= l along the path. The GOAL is end to end verifiability. >=20 > which is quite helpful. >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From hadriel.kaplan@oracle.com Tue Jun 11 12:25: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 35C8021F9113 for ; Tue, 11 Jun 2013 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 FDer47huvLwM for ; Tue, 11 Jun 2013 12:25:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AC94921F880F for ; Tue, 11 Jun 2013 12:25:26 -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 r5BJPJx9004610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 19:25:20 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 r5BJPLZW025976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 19:25:22 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5BJPL3b006759; Tue, 11 Jun 2013 19:25:21 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2013 12:25:21 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51B7583D.5020105@cs.tcd.ie> Date: Tue, 11 Jun 2013 15:25:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E06EA51-1EE9-4D40-9BA2-2EB739726F3C@oracle.com> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <51B7583D.5020105@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:25:33 -0000 On Jun 11, 2013, at 1:02 PM, Stephen Farrell = wrote: > Sure. I then send the cert to EFF and they add it to the > SSL observatory data set. Soon they'll have the mapping > for most keys to/from most phone numbers. I don't think that's a real concern. For one, each cert for each E.164 = would be unique; for another, it probably wouldn't be too hard to = convince EFF not to make the info available but only use it for their = own research purposes; third, it would take a large population of actors = posting the info to the EFF to make it interesting, but I don't see = commercial SIP devices doing that (and if they do they'd get themselves = on malware lists). I don't think that enough bad actors would receive = enough calls from enough sources to make any list they create really = useful. Realistically it's not like the list is truly secret - at least for = which carriers have which numbers, since any legitimate carrier can get = the info today already from LERG/NPAC/etc., which probably means anyone = can get a reasonably complete list for enough money today. The carriers = would like to keep it non-trivial (ie, prevent script kiddies). For = Enterprises it's even more of an issue/concern. Although my guess is = most of them wouldn't do this stuff themselves anyway, but have their = carrier do it for them, and thereby avoid such a problem. The above is assuming the cert databases are public to begin with, which = they might not be. I'm not even sure the signature with cert URL would = really be sent all the way to the endpoints, either. -hadriel From wilhelm@wimmreuter.de Tue Jun 11 12:32: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 1926C21F999B for ; Tue, 11 Jun 2013 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htsPFW9E5sqr for ; Tue, 11 Jun 2013 12:32:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02621F8FE5 for ; Tue, 11 Jun 2013 12:32:36 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LqWMz-1U8jdu0z2X-00doNB; Tue, 11 Jun 2013 21:32:31 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 99DD388ABBC; Tue, 11 Jun 2013 21:32:30 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 1E32188AB4C; Tue, 11 Jun 2013 21:32:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 11 Jun 2013 21:32:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B640D5.4000406@cs.tcd.ie> <808264A5-46B4-4244-9479-5EA445C326F4@oracle.com> <51B74EE6.2090103@dcrocker.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:orY/qCTjTDotZj2TPVspvdoAgr2exAQfyxUYtLqCMQP zdCagpX9nSOWriHItlV+VW/nkdYSzy+ZO4j4m4DRCzU5Ix3FRj +Iybbcrwvo4IHvqr2MoNfmagUOvdbiqjRSofHH7TZ9AOxNVmqK GasC1KlHChApCm2yZlCB/eFglbxNLVdwcnTO86L2DizERBr/22 zmcHjGBFomf4SYA96okINGPQCLsUaVOZKNVPZ8JumazTMm5ZXz EZgZ98//ZprXiay+V02im3CvlSdPzuOIf/kHF3QKUos3UK0lZp ekiKyCCGVZjkI0+5iPfUDo0b/K7ijBw2yEYvmftLXJDxiiykxo kf9Pmc32zUCLOsC+irrMRCEtTy/XL34fT97+jd0Ow Cc: "Rosen, Brian" , Hadriel Kaplan , dcrocker@bbiw.net, "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:32:41 -0000 These are important points on privacy! Do we need privacy for the users privacy or for service providers to = hide competitive advantages? I guess that all we need is a strong authentication of the originating = /requesting entity. This in turn means to separate authentication and certificate = attributes like identities such as phone numbers. What will be left: - A cert with a random Cname or alt-cname. Bound to a phone number / Caller-ID during enrollment - A signature digest to sign the=20 * originating CallerID / phone number (not necessary canonical) * Unique Call/Request ID (random) * Possibly a timestamp These signed elements must not be modified throughout the call path. = Therefore only a minimum set if attributes shall be signed. Of course, such systems will break at the interworking with PSTN as = mentioned before. However, the case is not hopeless as one could refer = to external databases holding the original signatures and attributes = stored before reaching a PSTN ingres point. This was already proposed by = Brian at the begin of this discussion. Such a system would allow to. - Authenticate caller IDs - Validate the signature at any point in the call path {except inside = PSTN) - Supress caller IDs where necessary e.g. subscribers, anonymous = help-lines, ... - Delegate authoritative use and signing e.g. for call-centers / PBXs ... legitimate spoofing ;-) - Delegate authoritative signing to the service provider. For endpoints that can not sign service requests. e.g. old SIP or PSTN = phones. - Direct access to enrollment registration e.g. 11 PSAPs or other = legitimate nosiness=20 - ... With that in mind, we possibly can resolve all other requirements like = canonical numbers, DKIM wish-lists, authorization and RoboCall issues on = top of such of such a base.=20 Willi On 11.06.2013, at 20:32, Henning Schulzrinne wrote: > I suspect access rules, both technical and legal, to any databases may = vary among countries. If the database stores public key - number pairs, = there is no particular need for an organization just to have one public = key, if it doesn't want to provide clues to its holdings.=20 >=20 > In general, for service providers, the assignment of numbers isn't = public, but it isn't a deep secret, either, at least among the entities = that likely have some competitive interest in this. The LERG contains = this information today, for example. >=20 > On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: >=20 >> On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >>> But anyway... one real downside with having a Public ENUM for a PKI = is that you could learn most or every number of an Enterprise or Service = Provider by just iterating the numbers. Even if the record reveals = nothing personal, you'll know which numbers belong to which = company/organization. >>=20 >>=20 >> if the target model is true end-to-end validation of number use, that = problem is going to be present, independent of the technical solution. >>=20 >> the only way to avoid that problem is to require that queries only be = among a trusted, regulated core. and from postings over the last couple = of days, it sounds as if that's /not/ the goal. (and irrelevantly i'll = add that i'm glad...) >>=20 >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> 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 >=20 From hadriel.kaplan@oracle.com Tue Jun 11 12:48: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 7BDEB21F972C for ; Tue, 11 Jun 2013 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 h7DmI0GVJYDd for ; Tue, 11 Jun 2013 12:48:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AB48521F9977 for ; Tue, 11 Jun 2013 12:48:06 -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 r5BJlEr8028128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 19:47:15 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 r5BJlGLF009467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 19:47:17 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5BJlGJB020754; Tue, 11 Jun 2013 19:47:16 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2013 12:47:15 -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, 11 Jun 2013 15:47:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49F87C2B-0427-47C8-9165-C0A7FCC579CB@oracle.com> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:48:14 -0000 Yup, but I'm not so sure carriers want to pay even more money to = third-party database companies for the privilege of accessing their own = data. ;) Although maybe it could be managed by each country's numbering plan = admin (e.g., NANPA)? If that were the case, then storing it in a Public = ENUM actually makes some sense. There would be no identifying = information - the cert wouldn't have the organization info in it, just = the phone number and issuer being NANPA. And from a DNS perspective = each country code sub-domain would all be under one authority (e.g., = *.1.stir.ietf.org would be NANPA), so they could split it out by = subdomains for the purpose of scaling servers without worrying about = authority problems. -hadriel On Jun 11, 2013, at 2:48 PM, Henning Schulzrinne = wrote: > As a side note, there is no particular need to store the mapping in = carrier-specific database. Today, databases are operated by various = third parties (NeutralTandem and kin, Neustar, obviously), so there's = plenty of opportunity to obscure this information, if desired. >=20 > On Jun 11, 2013, at 12:54 PM, Hadriel Kaplan wrote: >=20 >>=20 >> On Jun 11, 2013, at 10:45 AM, Stephen Farrell = wrote: >>=20 >>> I'm also confused as to why its a non-starter to have a >>> public database of public keys and phone numbers, but is ok >>> that anyone can build that database themselves, with fairly >>> modest effort. That seems odd to me anyway. (To be clear, >>> I do consider de-referencing a URL for a public key or >>> cert as a DB-lookup.) >>=20 >> If the mechanism uses a URL for de-referencing, then the structure of = the URL does not need to follow phone numbers in any way. So you = couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I = sign it and in the SIP INVITE I tell you to go get the cert from: >>=20 >> http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb >>=20 >> The cert you download says it's for "+1-212-555-1212" (e.g., in the = SAN field or something), and it's issuer is NANPA (North American = Numbering Plan Administration), which you presumably have locally known = root cert for and acceptance as a trusted CA. >>=20 >> So yes if you received the call from +1-212-555-1212 you'd know it's = an AT&T number (because of the URL's domain), but you wouldn't be able = to figure out what other numbers AT&T has - only those that called you. >>=20 >> Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" follows = a schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org". You don't = even need to receive a call. Just start querying all possible digits of = the fixed length/depth. For the 212 area code there are only 10 million = possible numbers. Even for all of the US it's only around a couple = billion, because most area codes haven't been allocated, and the list of = which ones have is public: >> = http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_co= des >>=20 >> -hadriel >> p.s. the above is not to say I think using HTTP is the right answer - = you can do the same thing with other database query protocols. The = point is the query key need not follow any number-based or well-known = schema. >>=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 brian.rosen@neustar.biz Tue Jun 11 12:48: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 A9FDA21F99C0 for ; Tue, 11 Jun 2013 12:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Amem93jlFgnn for ; Tue, 11 Jun 2013 12:48:25 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6698521F9458 for ; Tue, 11 Jun 2013 12:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370980173; x=1686337386; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=TX+8Eytl45 44lIm6hI5XPFZ3aNe6e3JrpH82JZOlM9Y=; b=m7N7MhaA6IiRRkdRIL8Xe6Kqzm pjkux47OPw1k74iIlYz6bGY/wLZoC0NIyY2p9LFE37WADB7ENShPQREPMUEQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24957862; Tue, 11 Jun 2013 15:49:32 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 15:46:30 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 15:46:25 -0400 From: "Rosen, Brian" To: Wilhelm Wimmreuter , Henning Schulzrinne Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvQaAgAE4igCAAAEjAIAAJDCAgAAQsQD//8DYgA== Date: Tue, 11 Jun 2013 19:46:25 +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.4.130416 x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: H5WM4Tt+7p8OkrNO96srPA== Content-Type: text/plain; charset="us-ascii" Content-ID: <36B11589C6120048A923C5946F78F242@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan , "dcrocker@bbiw.net" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:48:29 -0000 Right at the moment, I don't think we need to get into the level of detail over what is in the came/alt-cname. We might need to be thinking of what is in there, but maybe not where it goes. We have been discussing canonicalization of the from and to to get out of the problem that the actual from and to are changed by SBCs along the path. "bound to the phone number during enrollment" is not quite right. It's bound to the delegation of the number. That is not (necessarily) related to enrollment. Brian On 6/11/13 3:32 PM, "Wilhelm Wimmreuter" wrote: >These are important points on privacy! > Do we need privacy for the users privacy or for service providers to >hide competitive advantages? > >I guess that all we need is a strong authentication of the originating >/requesting entity. > > This in turn means to separate authentication and certificate attributes >like identities such as phone numbers. > >What will be left: >- A cert with a random Cname or alt-cname. > Bound to a phone number / Caller-ID during enrollment >- A signature digest to sign the > * originating CallerID / phone number (not necessary canonical) > * Unique Call/Request ID (random) > * Possibly a timestamp > > These signed elements must not be modified throughout the call path. >Therefore only a minimum set if attributes shall be signed. > > > >Of course, such systems will break at the interworking with PSTN as >mentioned before. However, the case is not hopeless as one could refer to >external databases holding the original signatures and attributes stored >before reaching a PSTN ingres point. This was already proposed by Brian >at the begin of this discussion. > > > >Such a system would allow to. >- Authenticate caller IDs >- Validate the signature at any point in the call path {except inside >PSTN) >- Supress caller IDs where necessary e.g. subscribers, anonymous >help-lines, ... >- Delegate authoritative use and signing e.g. for call-centers / PBXs > ... legitimate spoofing ;-) >- Delegate authoritative signing to the service provider. > For endpoints that can not sign service requests. e.g. old SIP or PSTN >phones. >- Direct access to enrollment registration e.g. 11 PSAPs or other >legitimate nosiness >- ... > >With that in mind, we possibly can resolve all other requirements like >canonical numbers, DKIM wish-lists, authorization and RoboCall issues on >top of such of such a base. > > >Willi > >On 11.06.2013, at 20:32, Henning Schulzrinne wrote: > >> I suspect access rules, both technical and legal, to any databases may >>vary among countries. If the database stores public key - number pairs, >>there is no particular need for an organization just to have one public >>key, if it doesn't want to provide clues to its holdings. >>=20 >> In general, for service providers, the assignment of numbers isn't >>public, but it isn't a deep secret, either, at least among the entities >>that likely have some competitive interest in this. The LERG contains >>this information today, for example. >>=20 >> On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: >>=20 >>> On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >>>> But anyway... one real downside with having a Public ENUM for a PKI >>>>is that you could learn most or every number of an Enterprise or >>>>Service Provider by just iterating the numbers. Even if the record >>>>reveals nothing personal, you'll know which numbers belong to which >>>>company/organization. >>>=20 >>>=20 >>> if the target model is true end-to-end validation of number use, that >>>problem is going to be present, independent of the technical solution. >>>=20 >>> the only way to avoid that problem is to require that queries only be >>>among a trusted, regulated core. and from postings over the last >>>couple of days, it sounds as if that's /not/ the goal. (and >>>irrelevantly i'll add that i'm glad...) >>>=20 >>>=20 >>> d/ >>>=20 >>> --=20 >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> _______________________________________________ >>> 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 >>=20 > From wilhelm@wimmreuter.de Tue Jun 11 12:49: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 8E9C221F9972 for ; Tue, 11 Jun 2013 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDGl0hykSnHL for ; Tue, 11 Jun 2013 12:49:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id DD79121F995E for ; Tue, 11 Jun 2013 12:49:40 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MQA9X-1UhFNB3p5f-005SKV; Tue, 11 Jun 2013 21:49:39 +0200 Received: by wwnet.ww (Postfix, from userid 783) id E0F5B88ABC8; Tue, 11 Jun 2013 21:49:37 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id D955C88AB4C; Tue, 11 Jun 2013 21:49:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <9E06EA51-1EE9-4D40-9BA2-2EB739726F3C@oracle.com> Date: Tue, 11 Jun 2013 21:49:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24A0317D-59E3-4DE4-9496-BA96C9498DEF@wimmreuter.de> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <51B7583D.5020105@cs.tcd.ie> <9E06EA51-1EE9-4D40-9BA2-2EB739726F3C@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:2uYL9jfv8xuiuudfHt3DoMfFfdkC7X8AjlZOdjHNmqa BSxHQUlcZ4VheExGkzz48azGgLdqez4s8YCQiaSTv5FRLWVdCW sCbSIrkBEkNzA5/oAnjRD+UVJBqm2OyEF/3R0DB6bvL5p3pigv ciup7fObAO41va4HwfsuJQKNEHocUD6gjSsR5l5hTIPoDsHQkP yJ72fFsXDWSqcW7ZeUt7gVEVTZhbs5q60RJRbdQTZJcNoL4zkG XOgzGvKn0TzUFaBUoa0PG//k3RrSnG/Rb60KXz9zwB2bA8S7+P C2W+xrd6cIlIHDcDTw3e5WWsHXQmEwUZqxeOqzUjsx1/4WNiw2 5VtAN5yYXLWWK+dif31tdCPgxf47aqi5zXX6195w/ Cc: stir@ietf.org, Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 19:49:50 -0000 See inline. Willi On 11.06.2013, at 21:25, Hadriel Kaplan wrote: >=20 > On Jun 11, 2013, at 1:02 PM, Stephen Farrell = wrote: >=20 >> Sure. I then send the cert to EFF and they add it to the >> SSL observatory data set. Soon they'll have the mapping >> for most keys to/from most phone numbers. >=20 > I don't think that's a real concern. For one, each cert for each = E.164 would be unique; for another, it probably wouldn't be too hard to = convince EFF not to make the info available but only use it for their = own research purposes; third, it would take a large population of actors = posting the info to the EFF to make it interesting, but I don't see = commercial SIP devices doing that (and if they do they'd get themselves = on malware lists). I don't think that enough bad actors would receive = enough calls from enough sources to make any list they create really = useful. I think we do not need one unique cert and private key for one E.164 = number. We can have more signing certs for a given E.164 number. The = only thing required is that the CA / RA performs a decent enrollment = check on the CSR for each potential certificate being created for a = given number. e.g. user, PABX, Service-provider, etc. >=20 > Realistically it's not like the list is truly secret - at least for = which carriers have which numbers, since any legitimate carrier can get = the info today already from LERG/NPAC/etc., which probably means anyone = can get a reasonably complete list for enough money today. The carriers = would like to keep it non-trivial (ie, prevent script kiddies). For = Enterprises it's even more of an issue/concern. Although my guess is = most of them wouldn't do this stuff themselves anyway, but have their = carrier do it for them, and thereby avoid such a problem. But this becomes an issue for legitimate anonymous identities / = caller-IDs >=20 > The above is assuming the cert databases are public to begin with, = which they might not be. I'm not even sure the signature with cert URL = would really be sent all the way to the endpoints, either. The cert databases shall be referred to as e.g. mentioned in RFC-4474. = The CAs and their databases shall be freely selectable bay users or = service-providers to allow competition and service-provider independent = choice.=20 >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From br@brianrosen.net Tue Jun 11 13:00: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 0D8EE21F99C9 for ; Tue, 11 Jun 2013 13:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.117 X-Spam-Level: X-Spam-Status: No, score=-100.117 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_24=0.6, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.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 jMZSKFJCbPnr for ; Tue, 11 Jun 2013 13:00:06 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id F3B4921F8CB4 for ; Tue, 11 Jun 2013 13:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=czP8VnGg1gDvfZDQ3/QEY2pjc8RVlAWdzmuHMvvpPjM=; b=KrhlhTkGpPRy5TXrqSfJyFlwC9rivjj13hIRykHjT0npUjIJOrXaADleV/SVtNjxbDb4FGpgInT1uQqkIhSOjAZ4r698QpOpgvov/Pq9cPSr9rj6rmbQjj4fzDEpLFlRLMjVT0gIzPte2+zecSu85K06MHoqEygUvRNHKmOMF38=; Received: from neustargw.va.neustar.com ([209.173.53.233]:40557 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UmUjd-0001cH-0m; Tue, 11 Jun 2013 16:00:05 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <49F87C2B-0427-47C8-9165-C0A7FCC579CB@oracle.com> Date: Tue, 11 Jun 2013 16:00:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <92CAB82D-A858-4D33-9814-4D64CD49B9DA@brianrosen.net> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <49F87C2B-0427-47C8-9165-C0A7FCC579CB@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:00:10 -0000 If you put in in public enum, you have all of the problems of managing = the tree that eluded us. As a practical matter, you get carriers to pay = a third party database company to manage the +1 tree, a la cc1enum. =20 In the U.S., it could be NPAC that held the per-TN data. It already = does for most numbers. Having NPAC provide an ENUM query in e164.arpa = is certainly possible, but I think would be an enormous effort to get = approved. Having it supply a query to SPs based on a sane query = protocol like a web service would be better and much easier to get = fielded. Way too much baggage in ENUM I think. Brian On Jun 11, 2013, at 3:47 PM, Hadriel Kaplan = wrote: >=20 > Yup, but I'm not so sure carriers want to pay even more money to = third-party database companies for the privilege of accessing their own = data. ;) >=20 > Although maybe it could be managed by each country's numbering plan = admin (e.g., NANPA)? If that were the case, then storing it in a Public = ENUM actually makes some sense. There would be no identifying = information - the cert wouldn't have the organization info in it, just = the phone number and issuer being NANPA. And from a DNS perspective = each country code sub-domain would all be under one authority (e.g., = *.1.stir.ietf.org would be NANPA), so they could split it out by = subdomains for the purpose of scaling servers without worrying about = authority problems. >=20 > -hadriel >=20 >=20 > On Jun 11, 2013, at 2:48 PM, Henning Schulzrinne = wrote: >=20 >> As a side note, there is no particular need to store the mapping in = carrier-specific database. Today, databases are operated by various = third parties (NeutralTandem and kin, Neustar, obviously), so there's = plenty of opportunity to obscure this information, if desired. >>=20 >> On Jun 11, 2013, at 12:54 PM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> On Jun 11, 2013, at 10:45 AM, Stephen Farrell = wrote: >>>=20 >>>> I'm also confused as to why its a non-starter to have a >>>> public database of public keys and phone numbers, but is ok >>>> that anyone can build that database themselves, with fairly >>>> modest effort. That seems odd to me anyway. (To be clear, >>>> I do consider de-referencing a URL for a public key or >>>> cert as a DB-lookup.) >>>=20 >>> If the mechanism uses a URL for de-referencing, then the structure = of the URL does not need to follow phone numbers in any way. So you = couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I = sign it and in the SIP INVITE I tell you to go get the cert from: >>>=20 >>> http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb >>>=20 >>> The cert you download says it's for "+1-212-555-1212" (e.g., in the = SAN field or something), and it's issuer is NANPA (North American = Numbering Plan Administration), which you presumably have locally known = root cert for and acceptance as a trusted CA. >>>=20 >>> So yes if you received the call from +1-212-555-1212 you'd know it's = an AT&T number (because of the URL's domain), but you wouldn't be able = to figure out what other numbers AT&T has - only those that called you. >>>=20 >>> Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" = follows a schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org". You = don't even need to receive a call. Just start querying all possible = digits of the fixed length/depth. For the 212 area code there are only = 10 million possible numbers. Even for all of the US it's only around a = couple billion, because most area codes haven't been allocated, and the = list of which ones have is public: >>> = http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_co= des >>>=20 >>> -hadriel >>> p.s. the above is not to say I think using HTTP is the right answer = - you can do the same thing with other database query protocols. The = point is the query key need not follow any number-based or well-known = schema. >>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From wilhelm@wimmreuter.de Tue Jun 11 13:02: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 0B5F521F99D9 for ; Tue, 11 Jun 2013 13:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB0z8KWRd8HV for ; Tue, 11 Jun 2013 13:02:17 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 619A921F99D2 for ; Tue, 11 Jun 2013 13:01:59 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LkWoK-1UC45C2dfA-00aT66; Tue, 11 Jun 2013 22:01:58 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 23BFD88AD2A; Tue, 11 Jun 2013 22:01:58 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id B536888ABC8; Tue, 11 Jun 2013 22:01:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <51B7583D.5020105@cs.tcd.ie> Date: Tue, 11 Jun 2013 22:01:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <51B7583D.5020105@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:qj4rbxXoVVePk5MGUXgOxxN7Xw9uLxNu7FP8lpiEg+q d3eFw3ZzFaOai5LPkKFDd/VwdwR8jYk2PUI/8ehQehTcOJqtW6 wHOyT6FyYrmzj0inUMt007bJNrNBYEuEfH2qSsdLudj0J2csUK USVnIH/GzQrE3YehC1SOxofTYTzmodgNNSKYoODcyZlzzRCTpx VPdGblr6LepejPtsfLAHMUdhzpg8WhhwMdCUiODQj8SsD5grr1 pMoWDtCSkBf/sRmMwcgaMy1fa6RgaXxhPdjZ82BKUQzFRiFXSc 3iiVy6conY/oy/fbGdShLBTJC8JGSweDi5c11Zo5hWNfkEZQ78 Ap5Kpd+cOMwZCSS+0G1EKkwKvbKeFETDPUK3TfBoE Cc: Dan York , Hadriel Kaplan , "stir@ietf.org" , Dave Crocker , "" , "Rosen, Brian" Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:02:25 -0000 On 11.06.2013, at 19:02, Stephen Farrell wrote: > Sure. I then send the cert to EFF and they add it to the > SSL observatory data set. Soon they'll have the mapping > for most keys to/from most phone numbers. Very true! Why not just using a nickname or any anonymous identifier in the = (alt-)Cname and leave it to the signer to sign the asserted Caller-ID = number? This could be further verified by anyone receiving the signature and the = digest attributes later. All authoritative / legitimate validation clients the can validate the = asserted Caller-ID. All others can be sure the given Caller-ID was not = modified on the call-path. > ... >=20 > I agree that a public ENUM thing would be easier to > walk. DKIM has selectors in the DNS names and you only > get those from email headers so DKIM is about the same > as an RPKI analog in this respect if the selectors and > URLs are equally unpredictable. I guess that ENUM in that sense would break privacy requirements. Willi From wilhelm@wimmreuter.de Tue Jun 11 13:26: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 03E9921F9703 for ; Tue, 11 Jun 2013 13:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh3BiyuTEgv1 for ; Tue, 11 Jun 2013 13:26:40 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB321F8825 for ; Tue, 11 Jun 2013 13:26:34 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LqpOw-1U8ENX10ZW-00eafv; Tue, 11 Jun 2013 22:26:33 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 56C8288ADE7; Tue, 11 Jun 2013 22:26:32 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id A3A8088ABD8; Tue, 11 Jun 2013 22:26:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 11 Jun 2013 22:26:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:z3OmZcFbd6xWb7bAL58VuBXQRAtHw6L1NImnennxGqc q6UyaEmxV+MJXGkeWVkKWj0GIiGV5SG4bjuxeKp5x1eaBDIy3s ZlExRllJ91Ex55w69xk653E3STFNazBRnYvZ7NVeY7tjl3Sa14 XaVpiPWUlI0i5frMTqSXp4d9Lp6XjZjN+1oI9o0+Rykz38WqVK 3UcZmWO8K6GSozb2f6sm1G+GFpHaZz6qiRLrEOQXe6VqWhi9wB jjR0mVdNOWVYdcEgn6QPFHAVIM4kfM0nlP2sNcvhbiGTTBKnJq j5pDOb9QJiPq0u0VwdQZNhIPguv7gjcKblxbyyK1wR5sZ5v2sN cLw+hiWMyc1WzeNSjeMUxrH0WMM/oQc4CtrW/BiLO Cc: "stir@ietf.org" , Stephen Farrell , Hadriel Kaplan , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:26:45 -0000 On 11.06.2013, at 21:46, Rosen, Brian wrote: >=20 > We have been discussing canonicalization of the from and to to get out = of > the problem that the actual from and to are changed by SBCs along the = path. >=20 Got it. What if we avoid signing the to and from at all? One also could sign the random Call-Reference instead. The asserted Caller-ID then could be validated by authoritative = validation clients through the registration-authorities databases only. = All other client validations will only see that his request was = generated by an authenticated user. > "bound to the phone number during enrollment" is not quite right. = It's > bound to the delegation of the number. That is not (necessarily) = related > to enrollment. By enrollment I ment the Certificate signing / CSR validation by the CA = and this is the process where the authority creates the certificate and = enables the user or service-provider to sign for a given Caller-ID or in = case of service providers, Call-Centers or PBXs for multiple Caller-IDs. Willi >=20 > Brian >=20 > On 6/11/13 3:32 PM, "Wilhelm Wimmreuter" = wrote: >=20 >> These are important points on privacy! >> Do we need privacy for the users privacy or for service providers to >> hide competitive advantages? >>=20 >> I guess that all we need is a strong authentication of the = originating >> /requesting entity. >>=20 >> This in turn means to separate authentication and certificate = attributes >> like identities such as phone numbers. >>=20 >> What will be left: >> - A cert with a random Cname or alt-cname. >> Bound to a phone number / Caller-ID during enrollment >> - A signature digest to sign the >> * originating CallerID / phone number (not necessary canonical) >> * Unique Call/Request ID (random) >> * Possibly a timestamp >>=20 >> These signed elements must not be modified throughout the call path. >> Therefore only a minimum set if attributes shall be signed. >>=20 >>=20 >>=20 >> Of course, such systems will break at the interworking with PSTN as >> mentioned before. However, the case is not hopeless as one could = refer to >> external databases holding the original signatures and attributes = stored >> before reaching a PSTN ingres point. This was already proposed by = Brian >> at the begin of this discussion. >>=20 >>=20 >>=20 >> Such a system would allow to. >> - Authenticate caller IDs >> - Validate the signature at any point in the call path {except inside >> PSTN) >> - Supress caller IDs where necessary e.g. subscribers, anonymous >> help-lines, ... >> - Delegate authoritative use and signing e.g. for call-centers / PBXs >> ... legitimate spoofing ;-) >> - Delegate authoritative signing to the service provider. >> For endpoints that can not sign service requests. e.g. old SIP or = PSTN >> phones. >> - Direct access to enrollment registration e.g. 11 PSAPs or other >> legitimate nosiness >> - ... >>=20 >> With that in mind, we possibly can resolve all other requirements = like >> canonical numbers, DKIM wish-lists, authorization and RoboCall issues = on >> top of such of such a base. >>=20 >>=20 >> Willi >>=20 >> On 11.06.2013, at 20:32, Henning Schulzrinne wrote: >>=20 >>> I suspect access rules, both technical and legal, to any databases = may >>> vary among countries. If the database stores public key - number = pairs, >>> there is no particular need for an organization just to have one = public >>> key, if it doesn't want to provide clues to its holdings. >>>=20 >>> In general, for service providers, the assignment of numbers isn't >>> public, but it isn't a deep secret, either, at least among the = entities >>> that likely have some competitive interest in this. The LERG = contains >>> this information today, for example. >>>=20 >>> On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: >>>=20 >>>> On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >>>>> But anyway... one real downside with having a Public ENUM for a = PKI >>>>> is that you could learn most or every number of an Enterprise or >>>>> Service Provider by just iterating the numbers. Even if the = record >>>>> reveals nothing personal, you'll know which numbers belong to = which >>>>> company/organization. >>>>=20 >>>>=20 >>>> if the target model is true end-to-end validation of number use, = that >>>> problem is going to be present, independent of the technical = solution. >>>>=20 >>>> the only way to avoid that problem is to require that queries only = be >>>> among a trusted, regulated core. and from postings over the last >>>> couple of days, it sounds as if that's /not/ the goal. (and >>>> irrelevantly i'll add that i'm glad...) >>>>=20 >>>>=20 >>>> d/ >>>>=20 >>>> --=20 >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >>>> _______________________________________________ >>>> 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 >>>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From brian.rosen@neustar.biz Tue Jun 11 13:32: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 B940921F9A22 for ; Tue, 11 Jun 2013 13:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 2SwgnmsoVazo for ; Tue, 11 Jun 2013 13:32:11 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AB41021F8825 for ; Tue, 11 Jun 2013 13:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370982649; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=KrwZtsdGL+ D5+ymeGFirLBCvz3Lrvt6iiX8v2vFgcIY=; b=YzfSt+NQrWzZHU5ZIgmjlta+Eh i00WCqgEhqoy3+tUfQ2+LdsNqmOxeEo5y152mT7pgpOLegEfATf5SdCjwKCg== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20845500; Tue, 11 Jun 2013 16:30:48 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 16:31:41 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 16:31:36 -0400 From: "Rosen, Brian" To: Wilhelm Wimmreuter Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh7+XkN8dxvkGEm7GtBTdYV5NZkvvQaAgAE4igCAAAEjAIAAJDCAgAAQsQD//8DYgIAATjuAgAABfQA= Date: Tue, 11 Jun 2013 20:31:35 +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: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: W+56h1BmTjTl1Fsn/w+dFg== Content-Type: text/plain; charset="us-ascii" Content-ID: <6A0DDE7927FA6F40B22CB1B8AA3F574F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "stir@ietf.org" , "dcrocker@bbiw.net" , "Rosen, Brian" , Stephen Farrell , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:32:14 -0000 On Jun 11, 2013, at 4:26 PM, Wilhelm Wimmreuter wro= te: >=20 > On 11.06.2013, at 21:46, Rosen, Brian wrote: >>=20 >> We have been discussing canonicalization of the from and to to get out o= f >> the problem that the actual from and to are changed by SBCs along the pa= th. >>=20 > Got it. > What if we avoid signing the to and from at all? > One also could sign the random Call-Reference instead. because you could use that in a cut/paste attack by sending a call with the= same call id and completely different to/from > The asserted Caller-ID then could be validated by authoritative validatio= n clients through the registration-authorities databases only. All other cl= ient validations will only see that his request was generated by an authent= icated user. in many countries, there are entities other than the ones known by the regi= stration authorities who hand out numbers. They get the numbers from a car= rier known by the authorities, but resell them to an entity that is not kno= wn. We have to handle that case. >=20 >=20 >=20 >> "bound to the phone number during enrollment" is not quite right. It's >> bound to the delegation of the number. That is not (necessarily) relate= d >> to enrollment. > By enrollment I ment the Certificate signing / CSR validation by the CA a= nd this is the process where the authority creates the certificate and enab= les the user or service-provider to sign for a given Caller-ID or in case o= f service providers, Call-Centers or PBXs for multiple Caller-IDs. Ah, I thought you meant enrollment in the SIP domain, sorry. >=20 >=20 > Willi >=20 >>=20 >> Brian >>=20 >> On 6/11/13 3:32 PM, "Wilhelm Wimmreuter" wrote: >>=20 >>> These are important points on privacy! >>> Do we need privacy for the users privacy or for service providers to >>> hide competitive advantages? >>>=20 >>> I guess that all we need is a strong authentication of the originating >>> /requesting entity. >>>=20 >>> This in turn means to separate authentication and certificate attribute= s >>> like identities such as phone numbers. >>>=20 >>> What will be left: >>> - A cert with a random Cname or alt-cname. >>> Bound to a phone number / Caller-ID during enrollment >>> - A signature digest to sign the >>> * originating CallerID / phone number (not necessary canonical) >>> * Unique Call/Request ID (random) >>> * Possibly a timestamp >>>=20 >>> These signed elements must not be modified throughout the call path. >>> Therefore only a minimum set if attributes shall be signed. >>>=20 >>>=20 >>>=20 >>> Of course, such systems will break at the interworking with PSTN as >>> mentioned before. However, the case is not hopeless as one could refer = to >>> external databases holding the original signatures and attributes store= d >>> before reaching a PSTN ingres point. This was already proposed by Brian >>> at the begin of this discussion. >>>=20 >>>=20 >>>=20 >>> Such a system would allow to. >>> - Authenticate caller IDs >>> - Validate the signature at any point in the call path {except inside >>> PSTN) >>> - Supress caller IDs where necessary e.g. subscribers, anonymous >>> help-lines, ... >>> - Delegate authoritative use and signing e.g. for call-centers / PBXs >>> ... legitimate spoofing ;-) >>> - Delegate authoritative signing to the service provider. >>> For endpoints that can not sign service requests. e.g. old SIP or PSTN >>> phones. >>> - Direct access to enrollment registration e.g. 11 PSAPs or other >>> legitimate nosiness >>> - ... >>>=20 >>> With that in mind, we possibly can resolve all other requirements like >>> canonical numbers, DKIM wish-lists, authorization and RoboCall issues o= n >>> top of such of such a base. >>>=20 >>>=20 >>> Willi >>>=20 >>> On 11.06.2013, at 20:32, Henning Schulzrinne wrote: >>>=20 >>>> I suspect access rules, both technical and legal, to any databases may >>>> vary among countries. If the database stores public key - number pairs= , >>>> there is no particular need for an organization just to have one publi= c >>>> key, if it doesn't want to provide clues to its holdings. >>>>=20 >>>> In general, for service providers, the assignment of numbers isn't >>>> public, but it isn't a deep secret, either, at least among the entitie= s >>>> that likely have some competitive interest in this. The LERG contains >>>> this information today, for example. >>>>=20 >>>> On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: >>>>=20 >>>>> On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >>>>>> But anyway... one real downside with having a Public ENUM for a PKI >>>>>> is that you could learn most or every number of an Enterprise or >>>>>> Service Provider by just iterating the numbers. Even if the record >>>>>> reveals nothing personal, you'll know which numbers belong to which >>>>>> company/organization. >>>>>=20 >>>>>=20 >>>>> if the target model is true end-to-end validation of number use, that >>>>> problem is going to be present, independent of the technical solution= . >>>>>=20 >>>>> the only way to avoid that problem is to require that queries only be >>>>> among a trusted, regulated core. and from postings over the last >>>>> couple of days, it sounds as if that's /not/ the goal. (and >>>>> irrelevantly i'll add that i'm glad...) >>>>>=20 >>>>>=20 >>>>> d/ >>>>>=20 >>>>> --=20 >>>>> Dave Crocker >>>>> Brandenburg InternetWorking >>>>> bbiw.net >>>>> _______________________________________________ >>>>> 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 >>>>=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 wilhelm@wimmreuter.de Tue Jun 11 13:37: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 CC96321F8BC0 for ; Tue, 11 Jun 2013 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpFJ2T9f-s9i for ; Tue, 11 Jun 2013 13:37:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id CC82421F99C2 for ; Tue, 11 Jun 2013 13:37:16 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MbgsX-1V2nmO1Mvd-00J4dA; Tue, 11 Jun 2013 22:37:13 +0200 Received: by wwnet.ww (Postfix, from userid 783) id BE22888AE5C; Tue, 11 Jun 2013 22:37:12 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 42F0088AD48; Tue, 11 Jun 2013 22:37:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <51B74C64.4070302@dcrocker.net> Date: Tue, 11 Jun 2013 22:37:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DDB5576-CAEF-453C-8C90-0C6709DAD84F@neustar.biz> <172B7D9C-1E4F-49C7-90E5-5848682625CF@cs.columbia.edu> <15ABDCF6-F127-4E8B-807F-FC3FAD78B905@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DAAEF@ex2k10mb2.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3A03DB34C@ex2k10mb2.corp.yaanatech.com> <02A4880B-8DBE-48D8-A5EC-DD82EC282527@neustar.biz> <51B74C64.4070302@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:yFWEJxRzlj6R2/7RnLc7vhHSY4cUyKQvYw4ubVMeOQA 4ti8Qcw9CPq8XZDOXG6xhr5DtvTSAR9FVJvxmJqSh7Wbf41mS4 WfenC9w/GB/rc6h3qzb7IConb12DcrI2swUxytpEfJ0I7vc2Hx xCWU0qya4BISnsfb6qmw2eqS7Oy/NnE7mlg7+0SVOLJAoBv+Vo 1w6zdIy2vP3Explo7C1/2SejueA1a6OZ6axpfNfS/6uzGSRdBh pkA/3eVXkY8qEXzCgWLiEwLoJn4HVgD9yIReNFPMkDTvM5E6Nx ffUXgIkI7DbTQO/YOvf6dwfmEG0U/J7R2OpouOtfqsAJ8RRE+d JP7MS5sTDT7HbwYkVWlpugYg485tuIMWm4t3JhFy0 Cc: "Rosen, Brian" , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:37:31 -0000 Guess this is MITM is the next VoIP issue to come up. Both way authentication is not considered for VoIP because service = providers are trusted by default. ;-) DANE WG with their DNSsec approach might be a solution for this MITM = issues as well? BTWY: We had nasty routing issues in pure PSTN as well. There the MITM could = pretend being a fixed network operator instead of a mobile operator to = "optimize" their business case on termination fees. Willi On 11.06.2013, at 18:12, Dave Crocker wrote: > On 6/11/2013 6:03 AM, Rosen, Brian wrote: >> MITM is a potential problem, which would be desirable to cut off, but = it's not the stated problem we're trying to solve. >>=20 >> There may be some number of service providers in the path that are = tolerant of the problem, but not really complicit. >=20 >=20 > This could have a pretty substantial effect on design choices. >=20 > For example, session-based SSL authentication -- that is, without = server validation (certs) -- permits MITM, which seems to be = often/generally acceptable in terms of actual practice, although = rhetoric claims otherwise. >=20 > But in general, I've had the impression that any effort at = authentication or confidentiality comes with an expectation of = resistance to MITM compromises. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From brian.rosen@neustar.biz Tue Jun 11 13:42: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 BA8A721F99BC for ; Tue, 11 Jun 2013 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 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 zeDcJ4hDrYxs for ; Tue, 11 Jun 2013 13:42:07 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id C86BC21F957B for ; Tue, 11 Jun 2013 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370983259; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=HdWs+Q5qSU Tt9ot4U/lRQGMe5AzyPFtkwyCpAd9n1y8=; b=nx/Jji/jpoZqHEvtjU0JyAt17/ TGZ77Hximpn29n9KAelvgfz4M5OeIy5h2bES+xPDhIvRgdzoxr+XhZ1RejAg== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20846001; Tue, 11 Jun 2013 16:40:58 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 16:41:51 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 16:41:46 -0400 From: "Rosen, Brian" To: Wilhelm Wimmreuter , "dcrocker@bbiw.net" Thread-Topic: [stir] Permitted spoofing Thread-Index: AQHOY+81QVR2lI4PHEaFqY34c3fHK5ksZHCAgAADK4CAAAkdAIAD3+GAgABy0gCAADSqAIAASfaA//++QIA= Date: Tue, 11 Jun 2013 20:41:46 +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.4.130416 x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: MNOMkCc8KZptkrWozzwXKw== Content-Type: text/plain; charset="us-ascii" Content-ID: <1DD3564BE37419438BE64B6CAF3809BD@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Hammer , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" , "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 20:42:10 -0000 This is not just MITM. The bad guy just needs to receive any good call, and then use it to impersonate the person who called them. I think we need the To, From, some form of call-id and a timestamp to get a decent signature. We don't have domains in this discussion - we have telephone numbers, so I think DANE can't help us. Brian On 6/11/13 4:37 PM, "Wilhelm Wimmreuter" wrote: >Guess this is MITM is the next VoIP issue to come up. > >Both way authentication is not considered for VoIP because service >providers are trusted by default. ;-) > > >DANE WG with their DNSsec approach might be a solution for this MITM >issues as well? > > >BTWY: >We had nasty routing issues in pure PSTN as well. There the MITM could >pretend being a fixed network operator instead of a mobile operator to >"optimize" their business case on termination fees. > >Willi > > > > >On 11.06.2013, at 18:12, Dave Crocker wrote: > >> On 6/11/2013 6:03 AM, Rosen, Brian wrote: >>> MITM is a potential problem, which would be desirable to cut off, but >>>it's not the stated problem we're trying to solve. >>>=20 >>> There may be some number of service providers in the path that are >>>tolerant of the problem, but not really complicit. >>=20 >>=20 >> This could have a pretty substantial effect on design choices. >>=20 >> For example, session-based SSL authentication -- that is, without >>server validation (certs) -- permits MITM, which seems to be >>often/generally acceptable in terms of actual practice, although >>rhetoric claims otherwise. >>=20 >> But in general, I've had the impression that any effort at >>authentication or confidentiality comes with an expectation of >>resistance to MITM compromises. >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 > From wilhelm@wimmreuter.de Tue Jun 11 14:22: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 094F521F99F2 for ; Tue, 11 Jun 2013 14:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SoQZDP3bpZq for ; Tue, 11 Jun 2013 14:21:59 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF521F99E2 for ; Tue, 11 Jun 2013 14:21:58 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LkUcJ-1UEZAs1vFD-00bsz5; Tue, 11 Jun 2013 23:21:57 +0200 Received: by wwnet.ww (Postfix, from userid 783) id D019988B4A0; Tue, 11 Jun 2013 23:21:56 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 6C7F788ABC7; Tue, 11 Jun 2013 23:21:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 11 Jun 2013 23:21:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:4fbElwrfCQZAiuvI7yZRUki/o1IhMZF1pvXkVvDygw6 G3P+Ku5BxmVoYeOXUdoUNVv9nLaUmxLOERxDsSj60aLMngF5Ur 1qzvRnt4AWVoPeOKC9cpeSMqFNwj4XllKrU+x0jAxYQIfYFd32 5kxKKldrnS9OPbgFUR5mUf4L38rQh/EEgmlo8vjnKzX20w/EwP TOtyut+E7wAbVtPopgIsH5lpd2URbwb25KA8rYpkAE5+w48ELl ZG2Rp7HuYVhaJX+wA6ttygCwx8t8mSrstNZqNWG5L1vUKeA4lH NjToJF+SGbxMPNtH6qls+ETATlc5FhjxpVBVmtpdMHOnM1GKnL //OaNcqkL7dxsZ6VfNHTcYA94oV7tW5nNZ7XNT1Tg Cc: "stir@ietf.org" , Henning Schulzrinne , Hadriel Kaplan , "dcrocker@bbiw.net" , Stephen Farrell Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 21:22:04 -0000 >> On 11.06.2013, at 21:46, Rosen, Brian wrote: >>>=20 >>> We have been discussing canonicalization of the from and to to get = out of >>> the problem that the actual from and to are changed by SBCs along = the path. >>>=20 >> Got it. >> What if we avoid signing the to and from at all? >> One also could sign the random Call-Reference instead. > because you could use that in a cut/paste attack by sending a call = with the same call id and completely different to/from Yes, that is true. So we have to include the to / from in the digest and forward the = original to / from unmodified somehow.=20 ... do we need another "behave" WG for to/from header handling besides = NAT ;-) Sorry for taking my shortcuts to far. >=20 >> The asserted Caller-ID then could be validated by authoritative = validation clients through the registration-authorities databases only. = All other client validations will only see that his request was = generated by an authenticated user. > in many countries, there are entities other than the ones known by the = registration authorities who hand out numbers. They get the numbers = from a carrier known by the authorities, but resell them to an entity = that is not known. We have to handle that case. Here I thought that we shall separate phone number registration = authorities from Certificate Authorities that sign the certificate and = in fact bind a certificate to one or multiple phone numbers / = caller-IDs. of course, both RAs can be the same required and capable. 1.) Phone number assigned to=20 Handout number Phone number RA=20 2.) Assign phone number to certificate for signing Certificate Authority & RA (sign the CSR) 3.) User or service provider on behalf of user signs the request. 4.) Validation - everyone in the call-path can validate the signature and message = consistency - legitimate users can also validate the asserted Caller-ID, = delegation etc. 5.) Out of band validation and optional re-signing across PSTN domains = is possible. e.g. through dynamic (out of band) databases with stringent time = constrains etc. >>=20 >>=20 >>=20 >>> "bound to the phone number during enrollment" is not quite right. = It's >>> bound to the delegation of the number. That is not (necessarily) = related >>> to enrollment. >> By enrollment I ment the Certificate signing / CSR validation by the = CA and this is the process where the authority creates the certificate = and enables the user or service-provider to sign for a given Caller-ID = or in case of service providers, Call-Centers or PBXs for multiple = Caller-IDs. > Ah, I thought you meant enrollment in the SIP domain, sorry. >=20 >>=20 >>=20 >> Willi >>=20 >>>=20 >>> Brian >>>=20 >>> On 6/11/13 3:32 PM, "Wilhelm Wimmreuter" = wrote: >>>=20 >>>> These are important points on privacy! >>>> Do we need privacy for the users privacy or for service providers = to >>>> hide competitive advantages? >>>>=20 >>>> I guess that all we need is a strong authentication of the = originating >>>> /requesting entity. >>>>=20 >>>> This in turn means to separate authentication and certificate = attributes >>>> like identities such as phone numbers. >>>>=20 >>>> What will be left: >>>> - A cert with a random Cname or alt-cname. >>>> Bound to a phone number / Caller-ID during enrollment >>>> - A signature digest to sign the >>>> * originating CallerID / phone number (not necessary canonical) >>>> * Unique Call/Request ID (random) >>>> * Possibly a timestamp >>>>=20 >>>> These signed elements must not be modified throughout the call = path. >>>> Therefore only a minimum set if attributes shall be signed. >>>>=20 >>>>=20 >>>>=20 >>>> Of course, such systems will break at the interworking with PSTN as >>>> mentioned before. However, the case is not hopeless as one could = refer to >>>> external databases holding the original signatures and attributes = stored >>>> before reaching a PSTN ingres point. This was already proposed by = Brian >>>> at the begin of this discussion. >>>>=20 >>>>=20 >>>>=20 >>>> Such a system would allow to. >>>> - Authenticate caller IDs >>>> - Validate the signature at any point in the call path {except = inside >>>> PSTN) >>>> - Supress caller IDs where necessary e.g. subscribers, anonymous >>>> help-lines, ... >>>> - Delegate authoritative use and signing e.g. for call-centers / = PBXs >>>> ... legitimate spoofing ;-) >>>> - Delegate authoritative signing to the service provider. >>>> For endpoints that can not sign service requests. e.g. old SIP or = PSTN >>>> phones. >>>> - Direct access to enrollment registration e.g. 11 PSAPs or other >>>> legitimate nosiness >>>> - ... >>>>=20 >>>> With that in mind, we possibly can resolve all other requirements = like >>>> canonical numbers, DKIM wish-lists, authorization and RoboCall = issues on >>>> top of such of such a base. >>>>=20 >>>>=20 >>>> Willi >>>>=20 >>>> On 11.06.2013, at 20:32, Henning Schulzrinne wrote: >>>>=20 >>>>> I suspect access rules, both technical and legal, to any databases = may >>>>> vary among countries. If the database stores public key - number = pairs, >>>>> there is no particular need for an organization just to have one = public >>>>> key, if it doesn't want to provide clues to its holdings. >>>>>=20 >>>>> In general, for service providers, the assignment of numbers isn't >>>>> public, but it isn't a deep secret, either, at least among the = entities >>>>> that likely have some competitive interest in this. The LERG = contains >>>>> this information today, for example. >>>>>=20 >>>>> On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote: >>>>>=20 >>>>>> On 6/11/2013 9:18 AM, Hadriel Kaplan wrote: >>>>>>> But anyway... one real downside with having a Public ENUM for a = PKI >>>>>>> is that you could learn most or every number of an Enterprise or >>>>>>> Service Provider by just iterating the numbers. Even if the = record >>>>>>> reveals nothing personal, you'll know which numbers belong to = which >>>>>>> company/organization. >>>>>>=20 >>>>>>=20 >>>>>> if the target model is true end-to-end validation of number use, = that >>>>>> problem is going to be present, independent of the technical = solution. >>>>>>=20 >>>>>> the only way to avoid that problem is to require that queries = only be >>>>>> among a trusted, regulated core. and from postings over the last >>>>>> couple of days, it sounds as if that's /not/ the goal. (and >>>>>> irrelevantly i'll add that i'm glad...) >>>>>>=20 >>>>>>=20 >>>>>> d/ >>>>>>=20 >>>>>> --=20 >>>>>> Dave Crocker >>>>>> Brandenburg InternetWorking >>>>>> bbiw.net >>>>>> _______________________________________________ >>>>>> 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 >>>>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From wilhelm@wimmreuter.de Tue Jun 11 14:35: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 0BE3621F9967 for ; Tue, 11 Jun 2013 14:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFOUGtt9VHp3 for ; Tue, 11 Jun 2013 14:35:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7BA21F9977 for ; Tue, 11 Jun 2013 14:35:16 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M4a7A-1URWxT1J6a-00zDhr; Tue, 11 Jun 2013 23:35:15 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 98B8F88BA2A; Tue, 11 Jun 2013 23:35:14 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id AA136888526; Tue, 11 Jun 2013 23:35:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Tue, 11 Jun 2013 23:35:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35573943-5A08-4CAB-AEA7-559B5F870F41@wimmreuter.de> References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:rwXo99JXY/x+AZgqzOlpjr0gm0tFxLsmNm4WTeSfJ6o 84BXsWf/xRRCdHYJD2gMyp1YaexFiVrrrdn7FH0xm/J6qdEbBV m2/xQJVt/jnLXmHEL7tnf51jUthM3oaMtKbppfzoJdpXufpqZa RRlxgBw4N5Ijnzo18PiSCgsyjJ3i6StK+1zM8GNj/SrEMRN+J5 os3IC5ZA7XKST9t4VCQBiq0hnFJG+Kt9M+OU39kzwv8lkVw7K1 R259XE65fXnUw89ZxC6JRaKUpGYk7HAxGl7oFK6DMFPuhV8KHe y8GCgdmqVR54GDkR1DeUDDPBSJ/2jzdd7pCzs/TmLJ7K4zaoB4 OhxlpOuOdzwkO4HzMa8C6/hEb/zO1XHOdMHJs8GrJ Cc: "hadriel.kaplan@oracle.com" , Michael Hammer , "dcrocker@bbiw.net" , "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 21:35:21 -0000 On 11.06.2013, at 22:41, Rosen, Brian wrote: > This is not just MITM. >=20 > The bad guy just needs to receive any good call, and then use it to > impersonate the person who called them. >=20 > I think we need the To, From, some form of call-id and a timestamp to = get > a decent signature. Yes, ... confessed in my previous message already ;-) > We don't have domains in this discussion - we have telephone numbers, = so I > think DANE can't help us. OK, but server authentication is definitely next. DNS is the only way to reach these servers today. We are farther on the = Internet than typical PSTN paradigms allow us to follow. SIP does not have decent server authentication and therefore one can = pretend to be your telecom server of choice. Willi >=20 > Brian >=20 > On 6/11/13 4:37 PM, "Wilhelm Wimmreuter" = wrote: >=20 >> Guess this is MITM is the next VoIP issue to come up. >>=20 >> Both way authentication is not considered for VoIP because service >> providers are trusted by default. ;-) >>=20 >>=20 >> DANE WG with their DNSsec approach might be a solution for this MITM >> issues as well? >>=20 >>=20 >> BTWY: >> We had nasty routing issues in pure PSTN as well. There the MITM = could >> pretend being a fixed network operator instead of a mobile operator = to >> "optimize" their business case on termination fees. >>=20 >> Willi >>=20 >>=20 >>=20 >>=20 >> On 11.06.2013, at 18:12, Dave Crocker wrote: >>=20 >>> On 6/11/2013 6:03 AM, Rosen, Brian wrote: >>>> MITM is a potential problem, which would be desirable to cut off, = but >>>> it's not the stated problem we're trying to solve. >>>>=20 >>>> There may be some number of service providers in the path that are >>>> tolerant of the problem, but not really complicit. >>>=20 >>>=20 >>> This could have a pretty substantial effect on design choices. >>>=20 >>> For example, session-based SSL authentication -- that is, without >>> server validation (certs) -- permits MITM, which seems to be >>> often/generally acceptable in terms of actual practice, although >>> rhetoric claims otherwise. >>>=20 >>> But in general, I've had the impression that any effort at >>> authentication or confidentiality comes with an expectation of >>> resistance to MITM compromises. >>>=20 >>> d/ >>>=20 >>> --=20 >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From hadriel.kaplan@oracle.com Tue Jun 11 14:36: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 9FB8221F9967 for ; Tue, 11 Jun 2013 14:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_24=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 9qFFY+xGWrMV for ; Tue, 11 Jun 2013 14:36:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3848521F9977 for ; Tue, 11 Jun 2013 14:36:50 -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 r5BLZQ20023247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 21:35:27 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 r5BLZRQh014111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 21:35:27 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5BLZQ9W021414; Tue, 11 Jun 2013 21:35:26 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2013 14:35: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: <92CAB82D-A858-4D33-9814-4D64CD49B9DA@brianrosen.net> Date: Tue, 11 Jun 2013 17:35:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DA592F8-E144-4B80-AA96-42993D2A6EAE@oracle.com> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <49F87C2B-0427-47C8-9165-C0A7FCC579CB@oracle.com> <92CAB82D-A858-4D33-9814-4D64CD49B9DA@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org, Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 11 Jun 2013 21:36:55 -0000 On Jun 11, 2013, at 4:00 PM, Brian Rosen wrote: > If you put in in public enum, you have all of the problems of managing = the tree that eluded us. As a practical matter, you get carriers to pay = a third party database company to manage the +1 tree, a la cc1enum. Not necessarily. For each country code, you make their numbering plan = admin the authority. For example for +1, you make NANPA the authority = (or maybe NANC or whatever it needs to be). They're "responsible" for = generating a unique key pair for each +1 E.164 signed by their root = cert, giving the key pair to the org they give the number to, and = hosting the pub key for each in a DNS structure. Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN = doesn't do the work for DNS. NANPA contracts with someone else to do = it, like Neustar (which as far as I know runs NANPA). Since they're = doing it all in bulk, then the per number entry it shouldn't cost = anywhere near what normal domain name registrations do. NANPA gets the = money for it from the E.164 number allocation fee, annual maintenance = fee, and change fee or whatever. I'm not saying getting this done is easy - it's NOT - but nothing we do = is going to be. At least this way there's only one organization to deal = with to get the cert-db part done, per country. > In the U.S., it could be NPAC that held the per-TN data. It already = does for most numbers. Having NPAC provide an ENUM query in e164.arpa = is certainly possible, but I think would be an enormous effort to get = approved. Having it supply a query to SPs based on a sane query = protocol like a web service would be better and much easier to get = fielded. Way too much baggage in ENUM I think. But the NPAC only holds data for NANP-based numbers. How does a US = carrier authenticate a number from the UK or Germany or wherever? -hadriel From dhc2@dcrocker.net Tue Jun 11 14:43: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 BCBD421F99FE for ; Tue, 11 Jun 2013 14:43:07 -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 jkwSMOqk7Rwi for ; Tue, 11 Jun 2013 14:43:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4C21F99ED for ; Tue, 11 Jun 2013 14:43:02 -0700 (PDT) Received: from [10.2.4.14] ([64.9.249.125]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5BLgwX4025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 14:43:02 -0700 Message-ID: <51B799DD.6070705@dcrocker.net> Date: Tue, 11 Jun 2013 14:42:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Wilhelm Wimmreuter References: <35573943-5A08-4CAB-AEA7-559B5F870F41@wimmreuter.de> In-Reply-To: <35573943-5A08-4CAB-AEA7-559B5F870F41@wimmreuter.de> 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, 11 Jun 2013 14:43:02 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Permitted spoofing 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, 11 Jun 2013 21:43:08 -0000 On 6/11/2013 2:35 PM, Wilhelm Wimmreuter wrote: > OK, but server authentication is definitely next. > DNS is the only way to reach these servers today. We are farther on the Internet than typical PSTN paradigms allow us to follow. > > SIP does not have decent server authentication and therefore one can pretend to be your telecom server of choice. Well... Server authentication is needed if the model is trust via the channel. It isn't needed if the trust goes with the data object, independent of the channel. DNSSec and DKIM are object-based. Of course, TLS is channel-based. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Tue Jun 11 18:03: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 8470821F9B8C for ; Tue, 11 Jun 2013 18:03:17 -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=[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 y+nJWQT4bb5o for ; Tue, 11 Jun 2013 18:03:13 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47D21F9B8B for ; Tue, 11 Jun 2013 18:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370999474; x=1686352102; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=kuRLpaW3n5OiM2gil7na3LWi9KJm8g6JvCzLIHxAE60=; b=mjYHslJXWFd+bWlii4CaZ9hqEFTPr2wiaktQetETqo8rhAh2gQu5xCUefht8bF JPZUpMjsXFUR8Q//x/vHVWaQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26140688; Tue, 11 Jun 2013 21:11:13 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 21:03:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 21:03:01 -0400 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gmw== Date: Wed, 12 Jun 2013 01:02:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: AbSpviMhW3q0TdZYyisypA== Content-Type: multipart/alternative; boundary="_000_CDDD16D01EE9Djonpetersonneustarbiz_" MIME-Version: 1.0 Subject: [stir] current draft 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, 12 Jun 2013 01:03:17 -0000 --_000_CDDD16D01EE9Djonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Below is the current draft of the charter, based on our prior discussions. Jon Peterson Neustar, Inc. ---- Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: TBD (Barnes) Mailing list: (current source-auth) To Subscribe: -- Over the last decade, a growing set of problems have resulted from the lack= of security mechanisms for attesting the origins of real-time communicatio= ns. Many of these problems are familiar from our experience with email: bul= k unsolicited commercial communications remain a challenge for the traditio= nal telephone network largely because the source of calls can be hidden. Ot= hers are potentially more serious: voicemail hacking, impersonating banks a= nd similar attacks are becoming commonplace. The technologies that obscure = the caller=92s identity are frequently gateways between the telephone netwo= rk and the Internet. SIP is one of the main VoIP technologies employed by these gateways. A numb= er of previous efforts have attacked the problem of securing the origins of= SIP communications, including RFC3325, RFC4474 and the VIPR WG. To date, h= owever, true cryptographic authentication of the source of SIP calls has no= t seen any appreciable deployment. While several factors contributed to thi= s lack of success, two seem like the largest culprits: 1) the lack of any r= eal means of asserting authority over telephone numbers on the Internet; an= d 2) a misalignment of the integrity mechanisms proposed by RFC4474 with th= e highly interworked, mediated and policy-driven deployment environment tha= t has emerged for SIP. The VIPR alternative, while promising, faced apparen= tly unavoidable privacy problems and other significant deployment hurdles. Given the pressing difficulties caused by the lack of a useful identity sol= ution, the problem of securing the origins of SIP communication must be rev= isited. Because SIP deployments are so closely tied to the telephone networ= k, we moreover must investigate solutions that can work when one side of a = call is in the PSTN =96 or potentially even both. This will require a two-p= ronged approach: one prong relying on information carried in SIP signaling;= the other prong relying on forming out-of-band connections between IP endp= oints that are participating in a call. The changes to the RFC4474 approach to SIP signaling must include a new cap= ability for Identity assertions to cover telephone numbers, rather than dom= ain names. To conform with realistic deployments, we must also study ways t= o rebalance the requirements for the scope of RFC4474=92s integrity protect= ion to emphasize preventing third-party impersonation over preventing men-i= n-the-middle from capturing media. Finally, the solution must encompass an out-of-band means for endpoints to = establish identity when there is no direct SIP signaling path between them = available, due to interworking or similar factors. This working group will = investigate a means for Internet endpoints to discover one another in real = time to verify that a telephone call between them is in progress based on m= inimal evidence or configuration. This architecture will, to the degree tha= t is possible, reuse the credentials defined for telephone numbers for the = in-band signaling solution, and define a discovery mechanism that provides = better than hop-by-hop security. The working group will coordinate with the security area on certificate man= agement. The working group will coordinate with RAI area groups studying the problem= of signaling through existing deployments, including INSIPID. Identity is closely linked to privacy, and frequently one comes at the cost= of the other. This working group is not chartered to mandate the presence = of identity in SIP requests, and to the extent feasible it will find privac= y-friendly solutions that leak minimal information about calls to third par= ties. The working group will deliver the following: - A problem statement detailing the deployment environment and difficulties= motivate work on secure origins - A revision to SIP=92s identity features to provide several fixes: Changes to support certification for telephone numbers Changes to the signature - A document describing the certificate profile required to support telepho= ne numbers in certificates - A fallback mechanism to allow out-of-band identity establishment during c= all setup Milestones Sep 2013 Submit problem statement for Info Nov 2013 Submit RFC4474bis for PS Jan 2013 Submit TN cert profile for Info Mar 2014 Submit fallback for PS --_000_CDDD16D01EE9Djonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Below is the current draft of the charter, based on our prior discussi= ons.

Jon Peterson
Neustar, Inc.

----

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

Chairs: TBD
Area Advisor: TBD (Barnes)

Mailing list: (current source-auth)
To Subscribe: --

Over the last decade, a growing set of problems have resulted from the= lack of security mechanisms for attesting the origins of real-time communi= cations. Many of these problems are familiar from our experience with email= : bulk unsolicited commercial communications remain a challenge for the traditional telephone network largely because t= he source of calls can be hidden. Others are potentially more serious: voic= email hacking, impersonating banks and similar attacks are becoming commonp= lace. The technologies that obscure the caller=92s identity are frequently gateways between the telephone netw= ork and the Internet.

SIP is one of the main VoIP technologies employed by these gateways. A= number of previous efforts have attacked the problem of securing the origi= ns of SIP communications, including RFC3325, RFC4474 and the VIPR WG. To da= te, however, true cryptographic authentication of the source of SIP calls has not seen any appreciable dep= loyment. While several factors contributed to this lack of success, two see= m like the largest culprits: 1) the lack of any real means of asserting aut= hority over telephone numbers on the Internet; and 2) a misalignment of the integrity mechanisms proposed b= y RFC4474 with the highly interworked, mediated and policy-driven deploymen= t environment that has emerged for SIP. The VIPR alternative, while promisi= ng, faced apparently unavoidable privacy problems and other significant deployment hurdles.

Given the pressing difficulties caused by the lack of a useful identit= y solution, the problem of securing the origins of SIP communication must b= e revisited. Because SIP deployments are so closely tied to the telephone n= etwork, we moreover must investigate solutions that can work when one side of a call is in the PSTN =96 or pote= ntially even both. This will require a two-pronged approach: one prong rely= ing on information carried in SIP signaling; the other prong relying on for= ming out-of-band connections between IP endpoints that are participating in a call.

The changes to the RFC4474 approach to SIP signaling must include a ne= w capability for Identity assertions to cover telephone numbers, rather tha= n domain names. To conform with realistic deployments, we must also study w= ays to rebalance the requirements for the scope of RFC4474=92s integrity protection to emphasize preventing = third-party impersonation over preventing men-in-the-middle from capturing = media.

Finally, the solution must encompass an out-of-band means for endpoint= s to establish identity when there is no direct SIP signaling path between = them available, due to interworking or similar factors. This working group = will investigate a means for Internet endpoints to discover one another in real time to verify that a telephone = call between them is in progress based on minimal evidence or configuration= . This architecture will, to the degree that is possible, reuse the credent= ials defined for telephone numbers for the in-band signaling solution, and define a discovery mechanism that = provides better than hop-by-hop security.

The working group will coordinate with the security area on certificat= e management.

The working group will coordinate with RAI area groups studying the pr= oblem of signaling through existing deployments, including INSIPID.

Identity is closely linked to privacy, and frequently one comes at the= cost of the other. This working group is not chartered to mandate the pres= ence of identity in SIP requests, and to the extent feasible it will find p= rivacy-friendly solutions that leak minimal information about calls to third parties.

The working group will deliver the following:

- A problem statement detailing the deployment environment and difficu= lties motivate work on secure origins

- A revision to SIP=92s identity features to provide several fixes:
    Changes to support certification for telephone numbers
    Changes to the signature 

- A document describing the certificate profile required to support te= lephone numbers in certificates

- A fallback mechanism to allow out-of-band identity establishment dur= ing call setup

Milestones

Sep 2013   Submit problem statement for Info
Nov 2013   Submit RFC4474bis for PS
Jan 2013   Submit TN cert profile for Info
Mar 2014   Submit fallback for PS

--_000_CDDD16D01EE9Djonpetersonneustarbiz_-- From stephen.farrell@cs.tcd.ie Tue Jun 11 18:47: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 BFD4521F9B9B for ; Tue, 11 Jun 2013 18:47:31 -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=[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 dR-jdPFaCkjD for ; Tue, 11 Jun 2013 18:47:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3427B21F9B8A for ; Tue, 11 Jun 2013 18:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8190DBE7D; Wed, 12 Jun 2013 02:46:57 +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 SX0fVVT8irvM; Wed, 12 Jun 2013 02:46:51 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.72.23]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3FC44BE76; Wed, 12 Jun 2013 02:46:51 +0100 (IST) Message-ID: <51B7D300.5070106@cs.tcd.ie> Date: Wed, 12 Jun 2013 02:46:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 12 Jun 2013 01:47:31 -0000 So based on many recent mails, I'd suggest adding "and threat model" to the problem statement deliverable and s/certificate/key management/g might be better so as not to preclude a non-certificate based solution. And one near-nit: I think the term "identity" generates quite a bit of confusion and its generally better to talk about identifiers and not identities. In other cases that's more of a deal but since we're only dealing with phone numbers here its almost a nit. Cheers, S. On 06/12/2013 02:02 AM, Peterson, Jon wrote: > > Below is the current draft of the charter, based on our prior discussions. > > Jon Peterson > Neustar, Inc. > > ---- > > Name: Secure Telephone Identity Revisited (stir) > Area: RAI > > Chairs: TBD > Area Advisor: TBD (Barnes) > > Mailing list: (current source-auth) > To Subscribe: -- > > Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. Many of these problems are familiar from our experience with email: bulk unsolicited commercial communications remain a challenge for the traditional telephone network largely because the source of calls can be hidden. Others are potentially more serious: voicemail hacking, impersonating banks and similar attacks are becoming commonplace. The technologies that obscure the caller’s identity are frequently gateways between the telephone network and the Internet. > > SIP is one of the main VoIP technologies employed by these gateways. A number of previous efforts have attacked the problem of securing the origins of SIP communications, including RFC3325, RFC4474 and the VIPR WG. To date, however, true cryptographic authentication of the source of SIP calls has not seen any appreciable deployment. While several factors contributed to this lack of success, two seem like the largest culprits: 1) the lack of any real means of asserting authority over telephone numbers on the Internet; and 2) a misalignment of the integrity mechanisms proposed by RFC4474 with the highly interworked, mediated and policy-driven deployment environment that has emerged for SIP. The VIPR alternative, while promising, faced apparently unavoidable privacy problems and other significant deployment hurdles. > > Given the pressing difficulties caused by the lack of a useful identity solution, the problem of securing the origins of SIP communication must be revisited. Because SIP deployments are so closely tied to the telephone network, we moreover must investigate solutions that can work when one side of a call is in the PSTN – or potentially even both. This will require a two-pronged approach: one prong relying on information carried in SIP signaling; the other prong relying on forming out-of-band connections between IP endpoints that are participating in a call. > > The changes to the RFC4474 approach to SIP signaling must include a new capability for Identity assertions to cover telephone numbers, rather than domain names. To conform with realistic deployments, we must also study ways to rebalance the requirements for the scope of RFC4474’s integrity protection to emphasize preventing third-party impersonation over preventing men-in-the-middle from capturing media. > > Finally, the solution must encompass an out-of-band means for endpoints to establish identity when there is no direct SIP signaling path between them available, due to interworking or similar factors. This working group will investigate a means for Internet endpoints to discover one another in real time to verify that a telephone call between them is in progress based on minimal evidence or configuration. This architecture will, to the degree that is possible, reuse the credentials defined for telephone numbers for the in-band signaling solution, and define a discovery mechanism that provides better than hop-by-hop security. > > The working group will coordinate with the security area on certificate management. > > The working group will coordinate with RAI area groups studying the problem of signaling through existing deployments, including INSIPID. > > Identity is closely linked to privacy, and frequently one comes at the cost of the other. This working group is not chartered to mandate the presence of identity in SIP requests, and to the extent feasible it will find privacy-friendly solutions that leak minimal information about calls to third parties. > > The working group will deliver the following: > > - A problem statement detailing the deployment environment and difficulties motivate work on secure origins > > - A revision to SIP’s identity features to provide several fixes: > Changes to support certification for telephone numbers > Changes to the signature > > - A document describing the certificate profile required to support telephone numbers in certificates > > - A fallback mechanism to allow out-of-band identity establishment during call setup > > Milestones > > Sep 2013 Submit problem statement for Info > Nov 2013 Submit RFC4474bis for PS > Jan 2013 Submit TN cert profile for Info > Mar 2014 Submit fallback for PS > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From hgs@cs.columbia.edu Tue Jun 11 19:09: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 70EF021F9B7F for ; Tue, 11 Jun 2013 19:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 smRKwwfqOTZe for ; Tue, 11 Jun 2013 19:09:44 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3B21F9B60 for ; Tue, 11 Jun 2013 19:09:44 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5C29clU008827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jun 2013 22:09:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> Date: Tue, 11 Jun 2013 22:09:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 02:09:50 -0000 All known bad actors are the original caller. It would be hard to scale = up a MITM model - if you're a transit carrier, all the other entities = would drop you immediately if it becomes obvious that you're hijacking = calls (besides probably calling the Feds, as wiretapping and other = criminal acts are likely to be involved). You'd have to advertise = yourself as a cheap VoIP carrier, get consumer or small business = customers and then perpetrate your MITM conversion. That seems like a = very short-lived business plan. That said, we do see one specific case of callerID alteration in the = middle, for intercarrier compensation fraud. (Some carriers have been = known to "convert" a landline call to a mobile or VoIP call, or = intrastate to interstate, since they have lower ICC.) But that is also = detectable by the next carrier in the chain, who would be the one being = defrauded and thus very motivated to check the signature. On Jun 11, 2013, at 2:42 AM, Michael Hammer wrote: > All these use cases suggest that the original caller is the perp. > Do you have a use case where the original caller is not the perp? >=20 > Part of my issue is the complexity being introduced on the network > components that would likely bog everything down. > Hence, my trying to focus on where the perp likely is. From jon.peterson@neustar.biz Tue Jun 11 19:17: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 5999A21F9B99 for ; Tue, 11 Jun 2013 19:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.322 X-Spam-Level: X-Spam-Status: No, score=-106.322 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 x8XNcGhmF564 for ; Tue, 11 Jun 2013 19:17:15 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01821F9B98 for ; Tue, 11 Jun 2013 19:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371003615; x=1686346344; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=gSfeyE1ChD aWEK09uqN4QK8icnCfCYeNnSwacRBKOsA=; b=BiAeciSWXFpVjFaj3ZyO7Gf2rP jwh6xaejYxtYI0Ej6gzBUhPFWmtznsJhZqjZSQFHEOC+eJkGOO7uRlkC79bg== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24976371; Tue, 11 Jun 2013 22:20:14 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 22:17:12 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 22:17:07 -0400 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: stir input drafts Thread-Index: AQHOZxLvMKgrXUyAyUC5a0jA6RHudA== Date: Wed, 12 Jun 2013 02:17:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7qebUi+TRMKFdD4v/xuhqg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [stir] stir input drafts X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 02:17:19 -0000 For the benefit of those recently tuning in to this channel, the input drafts that kicked off the initial STIR discussion were the following: First, as a bit of background, ISOC asked the IAB to comment on some contributions to the WCIT process related to identifying the source of communications. These included a pretty diverse set of problems, which we addressed in a brief white paper that we then decided to immortalize as an I-D: http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 Henning saw that draft and asked to meet with a few IAB members and IETF contributors to discuss the telephone side of this problem in Orlando. He expressed particular interest in robocalling, as some of you may recall from his IAB plenary presentation. We took an action item to write a problem statement that focused on why we never managed to get identity right for SIP, and what may have changed that might give us new leverage: http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 Wracked with guilt over my own culpability in this mess, I got together with Cullen and EKR to discuss RFC4474, and to at least get down a statement of intention for what here needed fixing in the future. This tries to divide cleanly between the question of how to improve the coverage from signature (the Identity header) from how to specify credentials other than domain name certs (the Identity-Info header). http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 However, based on all of our prior discussions we knew that there were use cases where no amount of refining RFC4474 was going to help. Pretty much any use case that transited a PSTN gateway necessarily would need something different. We therefore started sketching out some strawmen for how we could attack that part of the problem by creating an out-of-band connection of some kind, without resorting the DHT of ViPR. EKR came up with a model for this that had less security problems than what I was thinking of, which is documented here: https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-callerid-fall back.txt Of course there are a slew of other related drafts, many of which have already been cited on the list here, as there has been investigation of the failings of prior work for more than a decade now. There is now a pressing need to address the problem, and the stars do seem to be aligning in terms of new avenues for solutions. We now return you to your regularly scheduled programming, already in progress... Jon Peterson Neustar, Inc. From jon.peterson@neustar.biz Tue Jun 11 19:29: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 571E021F9962 for ; Tue, 11 Jun 2013 19:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.139, 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 0fFMquNCYkSt for ; Tue, 11 Jun 2013 19:29:09 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAE921F995B for ; Tue, 11 Jun 2013 19:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371004636; x=1686352102; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=WLtW77Bmnl LuPBa8xq5uUE0DIYa/r3i6HEdbyXD9HBE=; b=NxDXNWfn91gJHhFVg9SL+4jlP4 usAlgKBBDQukBDsuEQGq+I8d1v8gXEWehzlPUQYHyuYgBBeKTGpgRUnwCodg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26142909; Tue, 11 Jun 2013 22:37:15 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 22:29:03 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 22:28:59 -0400 From: "Peterson, Jon" To: Stephen Farrell Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYA= Date: Wed, 12 Jun 2013 02:28:58 +0000 Message-ID: In-Reply-To: <51B7D300.5070106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9RgNUaAbNAsdGHseaCqWpg== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5982C21E41D0414CBDCD036DBD541D6C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 12 Jun 2013 02:29:13 -0000 On 6/11/13 6:46 PM, "Stephen Farrell" wrote: > >So based on many recent mails, I'd suggest adding "and threat model" >to the problem statement deliverable and s/certificate/key management/g >might be better so as not to preclude a non-certificate based >solution. Fine with adding a threat model to the problem statement. And non-certificate based key management solutions are in scope, sure. RFC4474bis lists in its action items studying how to point at DANE from the Identity-Info header, and this could extend to alternatives for credentials in the DNS. Ironically, back when we wrote RFC4474, we assumed there would be keys in public ENUM and that we'd solve the problem this way eventually. Lack of public ENUM (and to a lesser extent, tardiness of DNSSEC) back-burnered that plan. I'm personally less concerned about the syntax of the credentials than the authority structures behind them. >And one near-nit: I think the term "identity" generates quite a bit >of confusion and its generally better to talk about identifiers and >not identities. In other cases that's more of a deal but since we're >only dealing with phone numbers here its almost a nit. I hesitate to back out the term "identity" given that it's what we've used for more than ten years for this. The header even in RFC4474 is called Identity. The RFC3325 header is P-Asserted-Identity. I hear what you're saying - this signature is over an identifier - but it's pretty clear that this identifier serves as an identity. The calling TN, or a derivative from it, is what telephony UIs show their users when alerting for an incoming call. Whether CNAM does it in the PSTN, or your address book does on your smart phone, applications translate callings TNs into proper names of various kind to represent callers. To secure calling TNs is to secure the identity of the caller. Jon Peterson Neustar, Inc. > >Cheers, >S. > >On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>=20 >> Below is the current draft of the charter, based on our prior >>discussions. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> ---- >>=20 >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >>=20 >> Chairs: TBD >> Area Advisor: TBD (Barnes) >>=20 >> Mailing list: (current source-auth) >> To Subscribe: -- >>=20 >> Over the last decade, a growing set of problems have resulted from the >>lack of security mechanisms for attesting the origins of real-time >>communications. Many of these problems are familiar from our experience >>with email: bulk unsolicited commercial communications remain a >>challenge for the traditional telephone network largely because the >>source of calls can be hidden. Others are potentially more serious: >>voicemail hacking, impersonating banks and similar attacks are becoming >>commonplace. The technologies that obscure the caller=B9s identity are >>frequently gateways between the telephone network and the Internet. >>=20 >> SIP is one of the main VoIP technologies employed by these gateways. A >>number of previous efforts have attacked the problem of securing the >>origins of SIP communications, including RFC3325, RFC4474 and the VIPR >>WG. To date, however, true cryptographic authentication of the source of >>SIP calls has not seen any appreciable deployment. While several factors >>contributed to this lack of success, two seem like the largest culprits: >>1) the lack of any real means of asserting authority over telephone >>numbers on the Internet; and 2) a misalignment of the integrity >>mechanisms proposed by RFC4474 with the highly interworked, mediated and >>policy-driven deployment environment that has emerged for SIP. The VIPR >>alternative, while promising, faced apparently unavoidable privacy >>problems and other significant deployment hurdles. >>=20 >> Given the pressing difficulties caused by the lack of a useful identity >>solution, the problem of securing the origins of SIP communication must >>be revisited. Because SIP deployments are so closely tied to the >>telephone network, we moreover must investigate solutions that can work >>when one side of a call is in the PSTN =AD or potentially even both. This >>will require a two-pronged approach: one prong relying on information >>carried in SIP signaling; the other prong relying on forming out-of-band >>connections between IP endpoints that are participating in a call. >>=20 >> The changes to the RFC4474 approach to SIP signaling must include a new >>capability for Identity assertions to cover telephone numbers, rather >>than domain names. To conform with realistic deployments, we must also >>study ways to rebalance the requirements for the scope of RFC4474=B9s >>integrity protection to emphasize preventing third-party impersonation >>over preventing men-in-the-middle from capturing media. >>=20 >> Finally, the solution must encompass an out-of-band means for endpoints >>to establish identity when there is no direct SIP signaling path between >>them available, due to interworking or similar factors. This working >>group will investigate a means for Internet endpoints to discover one >>another in real time to verify that a telephone call between them is in >>progress based on minimal evidence or configuration. This architecture >>will, to the degree that is possible, reuse the credentials defined for >>telephone numbers for the in-band signaling solution, and define a >>discovery mechanism that provides better than hop-by-hop security. >>=20 >> The working group will coordinate with the security area on certificate >>management. >>=20 >> The working group will coordinate with RAI area groups studying the >>problem of signaling through existing deployments, including INSIPID. >>=20 >> Identity is closely linked to privacy, and frequently one comes at the >>cost of the other. This working group is not chartered to mandate the >>presence of identity in SIP requests, and to the extent feasible it will >>find privacy-friendly solutions that leak minimal information about >>calls to third parties. >>=20 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and >>difficulties motivate work on secure origins >>=20 >> - A revision to SIP=B9s identity features to provide several fixes: >> Changes to support certification for telephone numbers >> Changes to the signature >>=20 >> - A document describing the certificate profile required to support >>telephone numbers in certificates >>=20 >> - A fallback mechanism to allow out-of-band identity establishment >>during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Info >> Nov 2013 Submit RFC4474bis for PS >> Jan 2013 Submit TN cert profile for Info >> Mar 2014 Submit fallback for PS >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 From wilhelm@wimmreuter.de Wed Jun 12 01:43: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 58B6821F9BEA for ; Wed, 12 Jun 2013 01:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTyEWWsHM8SA for ; Wed, 12 Jun 2013 01:43:24 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56321F9BF1 for ; Wed, 12 Jun 2013 01:43:20 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lkkvg-1UEio63bKm-00b42f; Wed, 12 Jun 2013 10:43:18 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 47EBA88D68C; Wed, 12 Jun 2013 10:43:18 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 8FA0F88D457; Wed, 12 Jun 2013 10:43:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <51B799DD.6070705@dcrocker.net> Date: Wed, 12 Jun 2013 10:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35573943-5A08-4CAB-AEA7-559B5F870F41@wimmreuter.de> <51B799DD.6070705@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:H7h9RC/PUg9bgcRTKjK5m1u53/ZO7WpGPpbnJWH/IXx mVNGsQvOjXsmeqPbWxut7//k8Ous27neyfh1j3k2nNN6PJG/Gj tG3JaM96m8/l2Qjd5UBulOpciwuXZkgNzRsIBxYPcx/HXjERkJ IIKNx5kwIc9qrsyKLOFBlJlVnScB1I9AlTQFU6WS14kpQdni8K VDtr33MPLXOh0BLIuum4ehkB+6FGMNM/KCoaylrz0S3XBOoj6t I658y98aNqlI+jh3NKUmjYTB9msQID7L8qepUbL33opHmp7lQL Ua28xTah5EXXAEDem55kVWAXDxtyqpyLZ/qI/0cTOsoSDshgGn IosOlnmzPICojTcvgR4nUvmTxnKq37Mv+oc6IbFCq Cc: "stir@ietf.org" Subject: Re: [stir] Permitted spoofing X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 08:43:28 -0000 For the sake of strong authentication like secure Caller-ID we = definitely need object-based proof only. This is an important distinction I guess and we shall keep that in mind. Willi On 11.06.2013, at 23:42, Dave Crocker wrote: > On 6/11/2013 2:35 PM, Wilhelm Wimmreuter wrote: >> OK, but server authentication is definitely next. >> DNS is the only way to reach these servers today. We are farther on = the Internet than typical PSTN paradigms allow us to follow. >>=20 >> SIP does not have decent server authentication and therefore one can = pretend to be your telecom server of choice. >=20 >=20 > Well... >=20 > Server authentication is needed if the model is trust via the channel. >=20 > It isn't needed if the trust goes with the data object, independent of = the channel. >=20 > DNSSec and DKIM are object-based. Of course, TLS is channel-based. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From wilhelm@wimmreuter.de Wed Jun 12 02:05: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 F35CD21F998F for ; Wed, 12 Jun 2013 02:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTRTFPI2NIYp for ; Wed, 12 Jun 2013 02:04:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98C21F99FD for ; Wed, 12 Jun 2013 02:04:55 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0La0V7-1U3y271xBV-00mMfU; Wed, 12 Jun 2013 11:04:54 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 70CFE88D803; Wed, 12 Jun 2013 11:04:53 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id C34E888D3BB; Wed, 12 Jun 2013 11:04:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> Date: Wed, 12 Jun 2013 11:04:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:hOe530xFK0VS/aVCgeUVyU2Muh0oRnKKrESQZ2Bzklp ledoOiKnkvOYqENDy8FkY5zqtmgtTiHE1pJqxM1WMGN9xvHvE+ MPIODyz/6IznhLYo1421O+4pn8xffQcGo9OWvvyUltNikrwLeO rWpznq6KFwazchW+ylFgMxymv9raISxY4aqUFnobpp1gbhZPxP ZA8IObZCZlDrukvDuS5+4CDFCsXajUIfjaH9O7Mrv+4tPHNAjI N13PJJBOfUnqe3r51+n/CsfTTKx43SQk+mJRmKGST6DMYcOJ23 v6GcCSa9WDHamV5JeCPKucKORxXG1TM1O/1mYzgh3TEM1ffSUO zyhdqzC8Whzi5gnhYWL9e+YjvKa80E3URYm7XwBvi Cc: stir@ietf.org, Michael Hammer Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 09:05:01 -0000 I can confirm this MITM tweaking with a bunch of samples from PSTN = carriers around the world. This goes from 1.) Tweaks in routing to hide the class of service and = origin, 2.) Premature answer or delayed release to increase revenues, = 3.) Overflow routing through other carriers to avoid expensive = termination fees, 5.) Not delivering calls because of expensive = termination fees and many more.=20 The telecom-acts of different countries made up a myriad of new = business cases for such tricks. And yes, they even introduced = back-to-back-user-agents for PSTN to avoid roaming fees between mobile = networks. This was done by introducing racks of mobile network = personalities to interconnect networks without roaming.=20 ... of course they charged it to their customers ;-) Willi On 12.06.2013, at 04:09, Henning Schulzrinne wrote: > All known bad actors are the original caller. It would be hard to = scale up a MITM model - if you're a transit carrier, all the other = entities would drop you immediately if it becomes obvious that you're = hijacking calls (besides probably calling the Feds, as wiretapping and = other criminal acts are likely to be involved). You'd have to advertise = yourself as a cheap VoIP carrier, get consumer or small business = customers and then perpetrate your MITM conversion. That seems like a = very short-lived business plan. >=20 > That said, we do see one specific case of callerID alteration in the = middle, for intercarrier compensation fraud. (Some carriers have been = known to "convert" a landline call to a mobile or VoIP call, or = intrastate to interstate, since they have lower ICC.) But that is also = detectable by the next carrier in the chain, who would be the one being = defrauded and thus very motivated to check the signature. >=20 > On Jun 11, 2013, at 2:42 AM, Michael Hammer wrote: >=20 >> All these use cases suggest that the original caller is the perp. >> Do you have a use case where the original caller is not the perp? >>=20 >> Part of my issue is the complexity being introduced on the network >> components that would likely bog everything down. >> Hence, my trying to focus on where the perp likely is. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From philippe.fouquart@orange.com Wed Jun 12 02: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 05EE121F9AE3 for ; Wed, 12 Jun 2013 02:51:00 -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, 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 HGpLtRwcHdOm for ; Wed, 12 Jun 2013 02:50:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8121F9619 for ; Wed, 12 Jun 2013 02:50:54 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 566DF324C32; Wed, 12 Jun 2013 11:50:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D46164C071; Wed, 12 Jun 2013 11:50:48 +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; Wed, 12 Jun 2013 11:50:48 +0200 From: To: "Peterson, Jon" , "stir@ietf.org" Thread-Topic: current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxzvcA Date: Wed, 12 Jun 2013 09:50:48 +0000 Message-ID: <27770_1371030649_51B84479_27770_127_1_B5939C6860701C49AA39C5DA5189448B0A2BA6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" 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.5.21.113319 Subject: Re: [stir] current draft 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, 12 Jun 2013 09:51:00 -0000 Jon, The only comment I would have is on the general phrasing of the first parag= raph, which at least for an outsider, may sometimes seem to be focused on a= nonymous calls rather than on 'illegitimate' CPNs in general (whilst the "m= ore serious" problems that are listed there have indeed more to do with the= latter than the former).=20 If this restriction is not deliberate, maybe you want to say "can be hidden= or forged" instead of only "hidden" and "that obscure or falsify" as oppos= ed to only "obscure". Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pet= erson, Jon Sent: Wednesday, June 12, 2013 3:03 AM To: stir@ietf.org Subject: [stir] current draft charter Below is the current draft of the charter, based on our prior discussions. Jon Peterson Neustar, Inc. ---- Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: TBD (Barnes) Mailing list: (current source-auth) To Subscribe: -- Over the last decade, a growing set of problems have resulted from the lack= of security mechanisms for attesting the origins of real-time communicatio= ns. Many of these problems are familiar from our experience with email: bul= k unsolicited commercial communications remain a challenge for the traditio= nal telephone network largely because the source of calls can be hidden. Ot= hers are potentially more serious: voicemail hacking, impersonating banks a= nd similar attacks are becoming commonplace. The technologies that obscure = the caller's identity are frequently gateways between the telephone network= and the Internet. SIP is one of the main VoIP technologies employed by these gateways. A numb= er of previous efforts have attacked the problem of securing the origins of= SIP communications, including RFC3325, RFC4474 and the VIPR WG. To date, h= owever, true cryptographic authentication of the source of SIP calls has no= t seen any appreciable deployment. While several factors contributed to thi= s lack of success, two seem like the largest culprits: 1) the lack of any r= eal means of asserting authority over telephone numbers on the Internet; an= d 2) a misalignment of the integrity mechanisms proposed by RFC4474 with th= e highly interworked, mediated and policy-driven deployment environment tha= t has emerged for SIP. The VIPR alternative, while promising, faced apparen= tly unavoidable privacy problems and other significant deployment hurdles. Given the pressing difficulties caused by the lack of a useful identity sol= ution, the problem of securing the origins of SIP communication must be rev= isited. Because SIP deployments are so closely tied to the telephone networ= k, we moreover must investigate solutions that can work when one side of a = call is in the PSTN - or potentially even both. This will require a two-pro= nged approach: one prong relying on information carried in SIP signaling; t= he other prong relying on forming out-of-band connections between IP endpoi= nts that are participating in a call. The changes to the RFC4474 approach to SIP signaling must include a new cap= ability for Identity assertions to cover telephone numbers, rather than dom= ain names. To conform with realistic deployments, we must also study ways t= o rebalance the requirements for the scope of RFC4474's integrity protectio= n to emphasize preventing third-party impersonation over preventing men-in-= the-middle from capturing media. Finally, the solution must encompass an out-of-band means for endpoints to = establish identity when there is no direct SIP signaling path between them = available, due to interworking or similar factors. This working group will = investigate a means for Internet endpoints to discover one another in real = time to verify that a telephone call between them is in progress based on m= inimal evidence or configuration. This architecture will, to the degree tha= t is possible, reuse the credentials defined for telephone numbers for the = in-band signaling solution, and define a discovery mechanism that provides = better than hop-by-hop security. The working group will coordinate with the security area on certificate man= agement. The working group will coordinate with RAI area groups studying the problem= of signaling through existing deployments, including INSIPID. Identity is closely linked to privacy, and frequently one comes at the cost= of the other. This working group is not chartered to mandate the presence = of identity in SIP requests, and to the extent feasible it will find privac= y-friendly solutions that leak minimal information about calls to third par= ties. The working group will deliver the following: - A problem statement detailing the deployment environment and difficulties= motivate work on secure origins - A revision to SIP's identity features to provide several fixes: =A0 =A0 Changes to support certification for telephone numbers =A0 =A0 Changes to the signature=A0 - A document describing the certificate profile required to support telepho= ne numbers in certificates - A fallback mechanism to allow out-of-band identity establishment during c= all setup Milestones Sep 2013 =A0 Submit problem statement for Info Nov 2013 =A0 Submit RFC4474bis for PS Jan 2013 =A0 Submit TN cert profile for Info Mar 2014 =A0 Submit fallback for PS ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From wilhelm@wimmreuter.de Wed Jun 12 02:52: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 B611B21F9AF7 for ; Wed, 12 Jun 2013 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQclcoCGUXsj for ; Wed, 12 Jun 2013 02:52:35 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 972C021F9AD1 for ; Wed, 12 Jun 2013 02:52:34 -0700 (PDT) Received: from wwnet.ww (p5DE95C29.dip0.t-ipconnect.de [93.233.92.41]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lj4vO-1UD6G70UwA-00dD95; Wed, 12 Jun 2013 11:52:25 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 4E17B88E07A; Wed, 12 Jun 2013 11:52:24 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id DCAAE88D88B; Wed, 12 Jun 2013 11:52:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Wilhelm Wimmreuter In-Reply-To: <51B7D300.5070106@cs.tcd.ie> Date: Wed, 12 Jun 2013 11:52:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B7D300.5070106@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:/8bvb3pWPoMBQ/WHhRzvRv49q9XFykhZnagFmpzaRJp oiAfkQAh7HcylSGHGm7XxHxB9tLMBfrZmppwUYWd9pGZtS25OM HDWygKgNtO75HuSnHTqS/sREFxN0kJvHPZGQqx+Hzab2SaiDBq BDM7yqfGf1hV3ju4O/Eh7r0VNsntCtaIIBfCAHO1BnU2u58HUy i8x90EBnniTe9ww5hSMc4/qoaw6l2uFZfj8/Hwqe5e9iQjF2J8 R8v5l5KXOhruqN6mbch77jgWistNBiDMTafrQ0s0yaO+aB1hLI oDuAWA5u5ynrMV8kvaLcsTMji/YVoh36q2xghvNiTLyhPunseZ fdPV7ZF5tV3nj/MKC1G8YpqNuoylnyGyhDF5LA01U Cc: stir@ietf.org Subject: Re: [stir] current draft 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, 12 Jun 2013 09:52:49 -0000 Question on identifier usage: Could one think about a model where the identifier "phone number" is = asserted in the digest of the service request and signed by any = authorized identity of the originating authority or user? Identifier: Authoritative Signee: +1 xxx yyy zzzz Signs private key of assigned=20 or delegated certificate This cert does not necessary need the=20 phone number as a Cname or alt-cname This would solve a number of issues discussed in various threats I = think. It also would allow free binding to existing certificates and = could avoid generating yet another cert for each phone number.=20 We shall avoid ending up in the same lifetime management issues as we = know from passwords today. Willi On 12.06.2013, at 03:46, Stephen Farrell wrote: >=20 > So based on many recent mails, I'd suggest adding "and threat model" > to the problem statement deliverable and s/certificate/key = management/g > might be better so as not to preclude a non-certificate based > solution. >=20 > And one near-nit: I think the term "identity" generates quite a bit > of confusion and its generally better to talk about identifiers and > not identities. In other cases that's more of a deal but since we're > only dealing with phone numbers here its almost a nit. >=20 > Cheers, > S. >=20 > On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>=20 >> Below is the current draft of the charter, based on our prior = discussions. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> ---- >>=20 >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >>=20 >> Chairs: TBD >> Area Advisor: TBD (Barnes) >>=20 >> Mailing list: (current source-auth) >> To Subscribe: -- >>=20 >> Over the last decade, a growing set of problems have resulted from = the lack of security mechanisms for attesting the origins of real-time = communications. Many of these problems are familiar from our experience = with email: bulk unsolicited commercial communications remain a = challenge for the traditional telephone network largely because the = source of calls can be hidden. Others are potentially more serious: = voicemail hacking, impersonating banks and similar attacks are becoming = commonplace. The technologies that obscure the caller=92s identity are = frequently gateways between the telephone network and the Internet. >>=20 >> SIP is one of the main VoIP technologies employed by these gateways. = A number of previous efforts have attacked the problem of securing the = origins of SIP communications, including RFC3325, RFC4474 and the VIPR = WG. To date, however, true cryptographic authentication of the source of = SIP calls has not seen any appreciable deployment. While several factors = contributed to this lack of success, two seem like the largest culprits: = 1) the lack of any real means of asserting authority over telephone = numbers on the Internet; and 2) a misalignment of the integrity = mechanisms proposed by RFC4474 with the highly interworked, mediated and = policy-driven deployment environment that has emerged for SIP. The VIPR = alternative, while promising, faced apparently unavoidable privacy = problems and other significant deployment hurdles. >>=20 >> Given the pressing difficulties caused by the lack of a useful = identity solution, the problem of securing the origins of SIP = communication must be revisited. Because SIP deployments are so closely = tied to the telephone network, we moreover must investigate solutions = that can work when one side of a call is in the PSTN =96 or potentially = even both. This will require a two-pronged approach: one prong relying = on information carried in SIP signaling; the other prong relying on = forming out-of-band connections between IP endpoints that are = participating in a call. >>=20 >> The changes to the RFC4474 approach to SIP signaling must include a = new capability for Identity assertions to cover telephone numbers, = rather than domain names. To conform with realistic deployments, we must = also study ways to rebalance the requirements for the scope of RFC4474=92s= integrity protection to emphasize preventing third-party impersonation = over preventing men-in-the-middle from capturing media. >>=20 >> Finally, the solution must encompass an out-of-band means for = endpoints to establish identity when there is no direct SIP signaling = path between them available, due to interworking or similar factors. = This working group will investigate a means for Internet endpoints to = discover one another in real time to verify that a telephone call = between them is in progress based on minimal evidence or configuration. = This architecture will, to the degree that is possible, reuse the = credentials defined for telephone numbers for the in-band signaling = solution, and define a discovery mechanism that provides better than = hop-by-hop security. >>=20 >> The working group will coordinate with the security area on = certificate management. >>=20 >> The working group will coordinate with RAI area groups studying the = problem of signaling through existing deployments, including INSIPID. >>=20 >> Identity is closely linked to privacy, and frequently one comes at = the cost of the other. This working group is not chartered to mandate = the presence of identity in SIP requests, and to the extent feasible it = will find privacy-friendly solutions that leak minimal information about = calls to third parties. >>=20 >> The working group will deliver the following: >>=20 >> - A problem statement detailing the deployment environment and = difficulties motivate work on secure origins >>=20 >> - A revision to SIP=92s identity features to provide several fixes: >> Changes to support certification for telephone numbers >> Changes to the signature >>=20 >> - A document describing the certificate profile required to support = telephone numbers in certificates >>=20 >> - A fallback mechanism to allow out-of-band identity establishment = during call setup >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Info >> Nov 2013 Submit RFC4474bis for PS >> Jan 2013 Submit TN cert profile for Info >> Mar 2014 Submit fallback for PS >>=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 >=20 From stephen.farrell@cs.tcd.ie Wed Jun 12 03:15: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 1711021F9BC7 for ; Wed, 12 Jun 2013 03:15:04 -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 2seI-W1SMEA7 for ; Wed, 12 Jun 2013 03:15:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9620721F9B9E for ; Wed, 12 Jun 2013 03:14:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2C15BEB2; Wed, 12 Jun 2013 11:14:37 +0100 (IST) 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 RYtKeq3m5gW9; Wed, 12 Jun 2013 11:14:37 +0100 (IST) Received: from [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f] (unknown [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1E94BEA4; Wed, 12 Jun 2013 11:14:37 +0100 (IST) Message-ID: <51B84A0D.1000702@cs.tcd.ie> Date: Wed, 12 Jun 2013 11:14:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> In-Reply-To: <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, Michael Hammer Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 10:15:04 -0000 Hi Henning, On 06/12/2013 03:09 AM, Henning Schulzrinne wrote: > All known bad actors are the original caller. It would be hard to > scale up a MITM model - if you're a transit carrier, all the other > entities would drop you immediately if it becomes obvious that you're > hijacking calls (besides probably calling the Feds, as wiretapping > and other criminal acts are likely to be involved). You'd have to > advertise yourself as a cheap VoIP carrier, get consumer or small > business customers and then perpetrate your MITM conversion. That > seems like a very short-lived business plan. On the MITM thing, it does seem that we don't need to worry so much about it for these use-cases, which may lead to an easier to implement/deploy key management model (or not, we'll see). One concern I have though is whether or not it'd be ok to leave open potential spoof calls launched from e.g. a zombied home router to a callee on the home network. If the final model had exactly the same security properties as DKIM, then that would be an issue. If the final model were based on Brian's 5280-based ideas that threat would probably not be an issue. Or there may be ways to look up a signer public key over a TLS channel that'd work too. So this is one detail (whether or not that threat is a concern) that needs to be figured out when doing the threat model work. S. > > That said, we do see one specific case of callerID alteration in the > middle, for intercarrier compensation fraud. (Some carriers have been > known to "convert" a landline call to a mobile or VoIP call, or > intrastate to interstate, since they have lower ICC.) But that is > also detectable by the next carrier in the chain, who would be the > one being defrauded and thus very motivated to check the signature. > > On Jun 11, 2013, at 2:42 AM, Michael Hammer wrote: > >> All these use cases suggest that the original caller is the perp. >> Do you have a use case where the original caller is not the perp? >> >> Part of my issue is the complexity being introduced on the network >> components that would likely bog everything down. Hence, my trying >> to focus on where the perp likely is. > > _______________________________________________ stir mailing list > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir > From stephen.farrell@cs.tcd.ie Wed Jun 12 03:22: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 4F58121F9C1B for ; Wed, 12 Jun 2013 03:22:04 -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 m1B65O94wyXi for ; Wed, 12 Jun 2013 03:21:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7FD21F9A31 for ; Wed, 12 Jun 2013 03:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 182D9BEAA; Wed, 12 Jun 2013 11:21:30 +0100 (IST) 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 k8OCY6EHmO8A; Wed, 12 Jun 2013 11:21:30 +0100 (IST) Received: from [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f] (unknown [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1F59BEA4; Wed, 12 Jun 2013 11:21:29 +0100 (IST) Message-ID: <51B84BAA.8020004@cs.tcd.ie> Date: Wed, 12 Jun 2013 11:21:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 12 Jun 2013 10:22:05 -0000 Hi Jon, On 06/12/2013 03:28 AM, Peterson, Jon wrote: > > > On 6/11/13 6:46 PM, "Stephen Farrell" wrote: > >> >> So based on many recent mails, I'd suggest adding "and threat model" >> to the problem statement deliverable and s/certificate/key management/g >> might be better so as not to preclude a non-certificate based >> solution. > > Fine with adding a threat model to the problem statement. Lovely. > > And non-certificate based key management solutions are in scope, sure. > RFC4474bis lists in its action items studying how to point at DANE from > the Identity-Info header, and this could extend to alternatives for > credentials in the DNS. Ironically, back when we wrote RFC4474, we assumed > there would be keys in public ENUM and that we'd solve the problem this > way eventually. Lack of public ENUM (and to a lesser extent, tardiness of > DNSSEC) back-burnered that plan. I'm personally less concerned about the > syntax of the credentials than the authority structures behind them. That's a fair point. However, I'd argue that the difference between a DKIM-like and RPKI-like approach is far from just syntax. For example, in an RPKI-like approach the callee has to verify who delegated what to whom in order to check the signature (e.g. via 5280 NameConstraints). With a DKIM-like approach, that's done in some un- or differently-specified way by some infrastructure (before making the public key available) and isn't directly visible to the callee. That's definitely not just syntax I reckon. >> And one near-nit: I think the term "identity" generates quite a bit >> of confusion and its generally better to talk about identifiers and >> not identities. In other cases that's more of a deal but since we're >> only dealing with phone numbers here its almost a nit. > > I hesitate to back out the term "identity" given that it's what we've used > for more than ten years for this. I'm fine with that in this case. It'll probably come up though so just as well to try get it out of the way:-) S. > The header even in RFC4474 is called > Identity. The RFC3325 header is P-Asserted-Identity. I hear what you're > saying - this signature is over an identifier - but it's pretty clear that > this identifier serves as an identity. The calling TN, or a derivative > from it, is what telephony UIs show their users when alerting for an > incoming call. Whether CNAM does it in the PSTN, or your address book does > on your smart phone, applications translate callings TNs into proper names > of various kind to represent callers. To secure calling TNs is to secure > the identity of the caller. > > Jon Peterson > Neustar, Inc. > >> >> Cheers, >> S. >> >> On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>> >>> Below is the current draft of the charter, based on our prior >>> discussions. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> ---- >>> >>> Name: Secure Telephone Identity Revisited (stir) >>> Area: RAI >>> >>> Chairs: TBD >>> Area Advisor: TBD (Barnes) >>> >>> Mailing list: (current source-auth) >>> To Subscribe: -- >>> >>> Over the last decade, a growing set of problems have resulted from the >>> lack of security mechanisms for attesting the origins of real-time >>> communications. Many of these problems are familiar from our experience >>> with email: bulk unsolicited commercial communications remain a >>> challenge for the traditional telephone network largely because the >>> source of calls can be hidden. Others are potentially more serious: >>> voicemail hacking, impersonating banks and similar attacks are becoming >>> commonplace. The technologies that obscure the caller¹s identity are >>> frequently gateways between the telephone network and the Internet. >>> >>> SIP is one of the main VoIP technologies employed by these gateways. A >>> number of previous efforts have attacked the problem of securing the >>> origins of SIP communications, including RFC3325, RFC4474 and the VIPR >>> WG. To date, however, true cryptographic authentication of the source of >>> SIP calls has not seen any appreciable deployment. While several factors >>> contributed to this lack of success, two seem like the largest culprits: >>> 1) the lack of any real means of asserting authority over telephone >>> numbers on the Internet; and 2) a misalignment of the integrity >>> mechanisms proposed by RFC4474 with the highly interworked, mediated and >>> policy-driven deployment environment that has emerged for SIP. The VIPR >>> alternative, while promising, faced apparently unavoidable privacy >>> problems and other significant deployment hurdles. >>> >>> Given the pressing difficulties caused by the lack of a useful identity >>> solution, the problem of securing the origins of SIP communication must >>> be revisited. Because SIP deployments are so closely tied to the >>> telephone network, we moreover must investigate solutions that can work >>> when one side of a call is in the PSTN ­ or potentially even both. This >>> will require a two-pronged approach: one prong relying on information >>> carried in SIP signaling; the other prong relying on forming out-of-band >>> connections between IP endpoints that are participating in a call. >>> >>> The changes to the RFC4474 approach to SIP signaling must include a new >>> capability for Identity assertions to cover telephone numbers, rather >>> than domain names. To conform with realistic deployments, we must also >>> study ways to rebalance the requirements for the scope of RFC4474¹s >>> integrity protection to emphasize preventing third-party impersonation >>> over preventing men-in-the-middle from capturing media. >>> >>> Finally, the solution must encompass an out-of-band means for endpoints >>> to establish identity when there is no direct SIP signaling path between >>> them available, due to interworking or similar factors. This working >>> group will investigate a means for Internet endpoints to discover one >>> another in real time to verify that a telephone call between them is in >>> progress based on minimal evidence or configuration. This architecture >>> will, to the degree that is possible, reuse the credentials defined for >>> telephone numbers for the in-band signaling solution, and define a >>> discovery mechanism that provides better than hop-by-hop security. >>> >>> The working group will coordinate with the security area on certificate >>> management. >>> >>> The working group will coordinate with RAI area groups studying the >>> problem of signaling through existing deployments, including INSIPID. >>> >>> Identity is closely linked to privacy, and frequently one comes at the >>> cost of the other. This working group is not chartered to mandate the >>> presence of identity in SIP requests, and to the extent feasible it will >>> find privacy-friendly solutions that leak minimal information about >>> calls to third parties. >>> >>> The working group will deliver the following: >>> >>> - A problem statement detailing the deployment environment and >>> difficulties motivate work on secure origins >>> >>> - A revision to SIP¹s identity features to provide several fixes: >>> Changes to support certification for telephone numbers >>> Changes to the signature >>> >>> - A document describing the certificate profile required to support >>> telephone numbers in certificates >>> >>> - A fallback mechanism to allow out-of-band identity establishment >>> during call setup >>> >>> Milestones >>> >>> Sep 2013 Submit problem statement for Info >>> Nov 2013 Submit RFC4474bis for PS >>> Jan 2013 Submit TN cert profile for Info >>> Mar 2014 Submit fallback for PS >>> >>> >>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> > > From pp3129@att.com Wed Jun 12 05:33: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 3BBE321F99F6 for ; Wed, 12 Jun 2013 05:33:17 -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=[BAYES_00=-2.599, J_CHICKENPOX_24=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 1CwSRb3HbRfk for ; Wed, 12 Jun 2013 05:33:11 -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 776D211E80A2 for ; Wed, 12 Jun 2013 05:33:06 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 28a68b15.2aaaf6e4a940.100100.00-545.269233.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 12 Jun 2013 12:33:06 +0000 (UTC) X-MXL-Hash: 51b86a820cf2a13c-ba37d062ae13a878662ee400dd4fb2396f49eb07 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 08a68b15.0.100089.00-463.269200.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 12 Jun 2013 12:33:06 +0000 (UTC) X-MXL-Hash: 51b86a821324ed6c-ab760eb015b570d826d05d3be9cb7c86ee330da9 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 r5CCX47j020283; Wed, 12 Jun 2013 08:33:04 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5CCWv3C020252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 08:32:58 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 12 Jun 2013 12:32:37 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 08:32:42 -0400 From: "PFAUTZ, PENN L" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZuuUZTgI05u6LU2LR+FOR4prVpkyAqhw Date: Wed, 12 Jun 2013 12:32:41 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D604857FED@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <49F87C2B-0427-47C8-9165-C0A7FCC579CB@oracle.com> <92CAB82D-A858-4D33-9814-4D64CD49B9DA@brianrosen.net> <6DA592F8-E144-4B80-AA96-42993D2A6EAE@oracle.com> In-Reply-To: <6DA592F8-E144-4B80-AA96-42993D2A6EAE@oracle.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.20.146] X-AnalysisOut: [v=2.0 cv=Zd6qwLpA c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=9ZIJ4ZtLS1gA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=MFotdkRvOnQA:10 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8] X-AnalysisOut: [ a=4mi5sR9_Whw8MWcagvgA:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 a=qLM2rbJk0xScjkAA] X-AnalysisOut: [:21 a=A35Kf8y3A14qx_7y:21] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 12:33:17 -0000 I think Hadriel is on the right track. As to the globalization issue, my t= akeaway from efforts to build an authoritative global enum tree is that you= will need to work from national authorities up. If you get per country dat= a sources it will not be hard to link them together/interwork. This approach also provides some national flexibility. 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 Had= riel Kaplan Sent: Tuesday, June 11, 2013 5:35 PM To: Brian Rosen Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach On Jun 11, 2013, at 4:00 PM, Brian Rosen wrote: > If you put in in public enum, you have all of the problems of managing th= e tree that eluded us. As a practical matter, you get carriers to pay a th= ird party database company to manage the +1 tree, a la cc1enum. Not necessarily. For each country code, you make their numbering plan admi= n the authority. For example for +1, you make NANPA the authority (or mayb= e NANC or whatever it needs to be). They're "responsible" for generating a= unique key pair for each +1 E.164 signed by their root cert, giving the ke= y pair to the org they give the number to, and hosting the pub key for each= in a DNS structure. Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN doe= sn't do the work for DNS. NANPA contracts with someone else to do it, like= Neustar (which as far as I know runs NANPA). Since they're doing it all i= n bulk, then the per number entry it shouldn't cost anywhere near what norm= al domain name registrations do. NANPA gets the money for it from the E.16= 4 number allocation fee, annual maintenance fee, and change fee or whatever= . I'm not saying getting this done is easy - it's NOT - but nothing we do is = going to be. At least this way there's only one organization to deal with = to get the cert-db part done, per country. > In the U.S., it could be NPAC that held the per-TN data. It already does= for most numbers. Having NPAC provide an ENUM query in e164.arpa is certa= inly possible, but I think would be an enormous effort to get approved. Ha= ving it supply a query to SPs based on a sane query protocol like a web ser= vice would be better and much easier to get fielded. Way too much baggage = in ENUM I think. But the NPAC only holds data for NANP-based numbers. How does a US carrier= authenticate a number from the UK or Germany or wherever? -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Wed Jun 12 09: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 331DF21F9A08 for ; Wed, 12 Jun 2013 09:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 jEuXPsk+oOz4 for ; Wed, 12 Jun 2013 09:57:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B728321F96FE for ; Wed, 12 Jun 2013 09:57:01 -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 r5CGuk4I004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 16:56:48 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 r5CGujYY029051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 16:56:46 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 r5CGuiCk023881; Wed, 12 Jun 2013 16:56:45 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 09:56: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: <51B84A0D.1000702@cs.tcd.ie> Date: Wed, 12 Jun 2013 12:56:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B763E54-DE72-4855-A6AB-18E9A4DAC54F@oracle.com> References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> <51B84A0D.1000702@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org, Michael Hammer , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 16:57:07 -0000 On Jun 12, 2013, at 6:14 AM, Stephen Farrell = wrote: > One concern I have though is whether or not it'd be ok to leave > open potential spoof calls launched from e.g. a zombied home router > to a callee on the home network. If the final model had exactly > the same security properties as DKIM, then that would be an issue. > If the final model were based on Brian's 5280-based ideas that > threat would probably not be an issue. Or there may be ways to > look up a signer public key over a TLS channel that'd work too. I understand what a "zombied home router" is and what a "callee on the = home network" is, but I don't understand the case you're talking about. = Can you describe the scenario for how the attack would work/behave? One type of attack that we might have to worry about, that might be = called a MITM attack because the attacker becomes a type of MITM during = the attack: a malicious callee receiving a call and using the received = signature to initiate an outbound call during the short time the = signature is valid, spoofing the original caller. =20 This is described in: http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-00 Basically it boils down to us needing to distinguish legitimate = call-forwarding from malicious call-forwarding. Unfortunately none of = the possible solutions for it are very palatable, imho. -hadriel From dcrocker@bbiw.net Wed Jun 12 10:13: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 6C3EF21F9B1C for ; Wed, 12 Jun 2013 10:13:12 -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 i9MXbcUgd1k9 for ; Wed, 12 Jun 2013 10:13:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7100E21F9B33 for ; Wed, 12 Jun 2013 10:13:06 -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 r5CHCvFX014212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:13:00 -0700 Message-ID: <51B8AC13.5040502@bbiw.net> Date: Wed, 12 Jun 2013 10:12:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <51B84BAA.8020004@cs.tcd.ie> In-Reply-To: <51B84BAA.8020004@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 12 Jun 2013 10:13:01 -0700 (PDT) Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] current draft 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, 12 Jun 2013 17:13:12 -0000 On 6/12/2013 3:21 AM, Stephen Farrell wrote: > That's a fair point. However, I'd argue that the difference between > a DKIM-like and RPKI-like approach is far from just syntax. For > example, in an RPKI-like approach the callee has to verify who > delegated what to whom in order to check the signature (e.g. via > 5280 NameConstraints). With a DKIM-like approach, that's done in > some un- or differently-specified way by some infrastructure (before > making the public key available) and isn't directly visible to the > callee. That's definitely not just syntax I reckon. My simplistic description of the DKIM-like model is that the storage location constitutes the cert. The semantic of the cert is "the owner of this location authorizes use of the key". Since the 'location' is a place in the DNS, the owner of the domain name at that location is validating use of the private key. For very simple cert semantics like this, it works. Semantics that are more complex probably won't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Wed Jun 12 10:13: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 5E6E721E808C for ; Wed, 12 Jun 2013 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 3vqiDSJpXzDW for ; Wed, 12 Jun 2013 10:13:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D958621E805E for ; Wed, 12 Jun 2013 10:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F19ACBEAA; Wed, 12 Jun 2013 18:13:21 +0100 (IST) 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 iN0oKFkFUx2f; Wed, 12 Jun 2013 18:13:21 +0100 (IST) Received: from [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f] (unknown [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE7F3BEA4; Wed, 12 Jun 2013 18:13:21 +0100 (IST) Message-ID: <51B8AC31.3030608@cs.tcd.ie> Date: Wed, 12 Jun 2013 18:13:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> <51B84A0D.1000702@cs.tcd.ie> <3B763E54-DE72-4855-A6AB-18E9A4DAC54F@oracle.com> In-Reply-To: <3B763E54-DE72-4855-A6AB-18E9A4DAC54F@oracle.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org, Michael Hammer , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 17:13:48 -0000 On 06/12/2013 05:56 PM, Hadriel Kaplan wrote: > > On Jun 12, 2013, at 6:14 AM, Stephen Farrell wrote: > >> One concern I have though is whether or not it'd be ok to leave >> open potential spoof calls launched from e.g. a zombied home router >> to a callee on the home network. If the final model had exactly >> the same security properties as DKIM, then that would be an issue. >> If the final model were based on Brian's 5280-based ideas that >> threat would probably not be an issue. Or there may be ways to >> look up a signer public key over a TLS channel that'd work too. > > I understand what a "zombied home router" is and what a "callee on the home network" is, but I don't understand the case you're talking about. Can you describe the scenario for how the attack would work/behave? I guess bad-guy hacks my home router, then initiates a call from or via there to me in my living room making it look like the call comes from my bank. If the key management was precisely the same as DKIM's then he'd be able to feed me a public key to make it look like his signature is ok for the bank's telephone number since I use my home router for DNS as well. (Assuming my UA doesn't insist on DNSSEC.) > One type of attack that we might have to worry about, that might be called a MITM attack because the attacker becomes a type of MITM during the attack: a malicious callee receiving a call and using the received signature to initiate an outbound call during the short time the signature is valid, spoofing the original caller. > > This is described in: > http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-00 Don't have time to read that right now, will look later. S > > Basically it boils down to us needing to distinguish legitimate call-forwarding from malicious call-forwarding. Unfortunately none of the possible solutions for it are very palatable, imho. > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > From hgs@cs.columbia.edu Wed Jun 12 10:24: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 5E43F21F9123 for ; Wed, 12 Jun 2013 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 2T+8KpKHDpJN for ; Wed, 12 Jun 2013 10:24:04 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id BA37421F9BBC for ; Wed, 12 Jun 2013 10:23:37 -0700 (PDT) Received: from [172.20.24.193] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5CHNMWn011001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Jun 2013 13:23:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Henning Schulzrinne In-Reply-To: <51B8AC13.5040502@bbiw.net> Date: Wed, 12 Jun 2013 13:23:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu> References: <51B84BAA.8020004@cs.tcd.ie> <51B8AC13.5040502@bbiw.net> To: Dave Crocker X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "stir@ietf.org" , "Peterson, Jon" , Stephen Farrell Subject: Re: [stir] current draft 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, 12 Jun 2013 17:24:20 -0000 The simple semantics sounds similar to the RFC 4744 model for SIP URIs. = As discussed in various drafts, this model unfortunately doesn't work = well for the domain-less case, such as telephone numbers. On Jun 12, 2013, at 1:12 PM, Dave Crocker wrote: > On 6/12/2013 3:21 AM, Stephen Farrell wrote: >> That's a fair point. However, I'd argue that the difference between >> a DKIM-like and RPKI-like approach is far from just syntax. For >> example, in an RPKI-like approach the callee has to verify who >> delegated what to whom in order to check the signature (e.g. via >> 5280 NameConstraints). With a DKIM-like approach, that's done in >> some un- or differently-specified way by some infrastructure (before >> making the public key available) and isn't directly visible to the >> callee. That's definitely not just syntax I reckon. >=20 >=20 > My simplistic description of the DKIM-like model is that the storage = location constitutes the cert. >=20 > The semantic of the cert is "the owner of this location authorizes use = of the key". Since the 'location' is a place in the DNS, the owner of = the domain name at that location is validating use of the private key. >=20 > For very simple cert semantics like this, it works. Semantics that = are more complex probably won't. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From dcrocker@bbiw.net Wed Jun 12 10:40: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 E05F211E80F0 for ; Wed, 12 Jun 2013 10:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 eSwPFrpbfwN0 for ; Wed, 12 Jun 2013 10:40:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7321F99AE for ; Wed, 12 Jun 2013 10:40:41 -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 r5CHeSSn014904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:40:32 -0700 Message-ID: <51B8B287.7010005@bbiw.net> Date: Wed, 12 Jun 2013 10:40:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <51B84BAA.8020004@cs.tcd.ie> <51B8AC13.5040502@bbiw.net> <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu> In-Reply-To: <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 12 Jun 2013 10:40:32 -0700 (PDT) Cc: "stir@ietf.org" , "Peterson, Jon" , Stephen Farrell Subject: Re: [stir] current draft 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, 12 Jun 2013 17:40:47 -0000 On 6/12/2013 10:23 AM, Henning Schulzrinne wrote: > The simple semantics sounds similar to the RFC 4744 model for SIP URIs. As discussed in various drafts, this model unfortunately doesn't work well for the domain-less case, such as telephone numbers. Not definitionally, no, but of course we know it can be encoded as one. Ignoring the politics of that moves the discussion to a comparison of the choices among alternatives. At a minimum, any solution here has to provide cert semantics, encoding and operation, query protocol and integrated server operation. (There are probably some additional requirements, but these three will do for a start.) My understanding of the requirements for cert semantics here is that it's pretty trivial. Administering and enforcing it might not be, but the basic semantic quite simple. New protocols are expensive and risky, even when built on top of a solid technical infrastructure. We know that establishing a globally integrated set of server operations is risky to the point of being nearly impossible, based on a long history of many attempts and very, very few successes. (The word "integrated" is the challenge here -- the service being proposed here is for a unified number space; servers handling queries therefore need to compose into a unified service; for example this is quite different from fully independent web servers that might have pointers to each other.) My suggestion is that any proposed solution be considered carefully for comparative effort and risk. The challenge of course is to be fair to whatever choice isn't one's favorite. Perhaps a cliche, but on the average we think the challenges for the choice we prefer are less than they actually are, and for non-favorites higher than they actually are. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Wed Jun 12 10:50: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 79C6B11E8105 for ; Wed, 12 Jun 2013 10:50:06 -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 dBeCk-LRWDaO for ; Wed, 12 Jun 2013 10:50:01 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6711E80F7 for ; Wed, 12 Jun 2013 10:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371059577; x=1686416367; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=CEJqIZKy1f 1A3z0PGAGB8ojlwC1iAWCVdhxsgk0xSoY=; b=dGUqElFf7lZyEI3T1JHFEJXAdL ToDxt0V6mO0vzEiM5b4YuLoV1ShOYyjdJar2RidTxn0nabCl4OhzglEQ2V9Q== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25009757; Wed, 12 Jun 2013 13:52:56 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 13:49:52 -0400 From: "Peterson, Jon" To: Wilhelm Wimmreuter , Stephen Farrell Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloAgACHsICAABAQAA== Date: Wed, 12 Jun 2013 17:49:51 +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.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: kI8oR2gyfB6rusTjli0Afg== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8290A6C1A467744AA0C9691754121C08@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 12 Jun 2013 17:50:06 -0000 If I understand you correctly, I agree this is a model we should explore: one where an authority over a number (like a carrier) could sign a credential controlled by an end user, who then uses that delegated authority to assert identity in a SIP request. While the end user cert, as you say, conceivably might not have the phone number in its cname or subjectAltName or what have you, relying parties could verify that the credential that signed this end user cert does indeed have that authority in scope. I don't think anyone here expects a model where there would literally be a new certificate for every telephone number, but in some use cases, having a certificate for an individual telephone number might be appropriate. I don't think we need to make this an either/or choice, though, both models can coexist peaceably. Jon Peterson Neustar, Inc. On 6/12/13 2:52 AM, "Wilhelm Wimmreuter" wrote: >Question on identifier usage: > >Could one think about a model where the identifier "phone number" is >asserted in the digest of the service request and signed by any >authorized identity of the originating authority or user? > > >Identifier: Authoritative Signee: >+1 xxx yyy zzzz Signs private key of assigned > or delegated certificate > This cert does not necessary need the > phone number as a Cname or alt-cname > >This would solve a number of issues discussed in various threats I think. >It also would allow free binding to existing certificates and could avoid >generating yet another cert for each phone number. >We shall avoid ending up in the same lifetime management issues as we >know from passwords today. > >Willi >On 12.06.2013, at 03:46, Stephen Farrell wrote: > >>=20 >> So based on many recent mails, I'd suggest adding "and threat model" >> to the problem statement deliverable and s/certificate/key management/g >> might be better so as not to preclude a non-certificate based >> solution. >>=20 >> And one near-nit: I think the term "identity" generates quite a bit >> of confusion and its generally better to talk about identifiers and >> not identities. In other cases that's more of a deal but since we're >> only dealing with phone numbers here its almost a nit. >>=20 >> Cheers, >> S. >>=20 >> On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>>=20 >>> Below is the current draft of the charter, based on our prior >>>discussions. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> ---- >>>=20 >>> Name: Secure Telephone Identity Revisited (stir) >>> Area: RAI >>>=20 >>> Chairs: TBD >>> Area Advisor: TBD (Barnes) >>>=20 >>> Mailing list: (current source-auth) >>> To Subscribe: -- >>>=20 >>> Over the last decade, a growing set of problems have resulted from the >>>lack of security mechanisms for attesting the origins of real-time >>>communications. Many of these problems are familiar from our experience >>>with email: bulk unsolicited commercial communications remain a >>>challenge for the traditional telephone network largely because the >>>source of calls can be hidden. Others are potentially more serious: >>>voicemail hacking, impersonating banks and similar attacks are becoming >>>commonplace. The technologies that obscure the caller=B9s identity are >>>frequently gateways between the telephone network and the Internet. >>>=20 >>> SIP is one of the main VoIP technologies employed by these gateways. A >>>number of previous efforts have attacked the problem of securing the >>>origins of SIP communications, including RFC3325, RFC4474 and the VIPR >>>WG. To date, however, true cryptographic authentication of the source >>>of SIP calls has not seen any appreciable deployment. While several >>>factors contributed to this lack of success, two seem like the largest >>>culprits: 1) the lack of any real means of asserting authority over >>>telephone numbers on the Internet; and 2) a misalignment of the >>>integrity mechanisms proposed by RFC4474 with the highly interworked, >>>mediated and policy-driven deployment environment that has emerged for >>>SIP. The VIPR alternative, while promising, faced apparently >>>unavoidable privacy problems and other significant deployment hurdles. >>>=20 >>> Given the pressing difficulties caused by the lack of a useful >>>identity solution, the problem of securing the origins of SIP >>>communication must be revisited. Because SIP deployments are so closely >>>tied to the telephone network, we moreover must investigate solutions >>>that can work when one side of a call is in the PSTN =AD or potentially >>>even both. This will require a two-pronged approach: one prong relying >>>on information carried in SIP signaling; the other prong relying on >>>forming out-of-band connections between IP endpoints that are >>>participating in a call. >>>=20 >>> The changes to the RFC4474 approach to SIP signaling must include a >>>new capability for Identity assertions to cover telephone numbers, >>>rather than domain names. To conform with realistic deployments, we >>>must also study ways to rebalance the requirements for the scope of >>>RFC4474=B9s integrity protection to emphasize preventing third-party >>>impersonation over preventing men-in-the-middle from capturing media. >>>=20 >>> Finally, the solution must encompass an out-of-band means for >>>endpoints to establish identity when there is no direct SIP signaling >>>path between them available, due to interworking or similar factors. >>>This working group will investigate a means for Internet endpoints to >>>discover one another in real time to verify that a telephone call >>>between them is in progress based on minimal evidence or configuration. >>>This architecture will, to the degree that is possible, reuse the >>>credentials defined for telephone numbers for the in-band signaling >>>solution, and define a discovery mechanism that provides better than >>>hop-by-hop security. >>>=20 >>> The working group will coordinate with the security area on >>>certificate management. >>>=20 >>> The working group will coordinate with RAI area groups studying the >>>problem of signaling through existing deployments, including INSIPID. >>>=20 >>> Identity is closely linked to privacy, and frequently one comes at the >>>cost of the other. This working group is not chartered to mandate the >>>presence of identity in SIP requests, and to the extent feasible it >>>will find privacy-friendly solutions that leak minimal information >>>about calls to third parties. >>>=20 >>> The working group will deliver the following: >>>=20 >>> - A problem statement detailing the deployment environment and >>>difficulties motivate work on secure origins >>>=20 >>> - A revision to SIP=B9s identity features to provide several fixes: >>> Changes to support certification for telephone numbers >>> Changes to the signature >>>=20 >>> - A document describing the certificate profile required to support >>>telephone numbers in certificates >>>=20 >>> - A fallback mechanism to allow out-of-band identity establishment >>>during call setup >>>=20 >>> Milestones >>>=20 >>> Sep 2013 Submit problem statement for Info >>> Nov 2013 Submit RFC4474bis for PS >>> Jan 2013 Submit TN cert profile for Info >>> Mar 2014 Submit fallback for PS >>>=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 >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Wed Jun 12 11:20: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 E47CD11E80CC for ; Wed, 12 Jun 2013 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 pRpC96dh4P-7 for ; Wed, 12 Jun 2013 11:20:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97F21E8055 for ; Wed, 12 Jun 2013 11:20:05 -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 r5CIJsOu010007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 18:19: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 r5CIJrwh019469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 18:19: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 r5CIJq0j002762; Wed, 12 Jun 2013 18:19:52 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 11:19: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: <51B8AC31.3030608@cs.tcd.ie> Date: Wed, 12 Jun 2013 14:19:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CC39DA7-8610-4284-B51E-5FA7E2A59C0F@neustar.biz> <51B225E9.8050206@bbiw.net> <200A4AFC-8397-4AF8-806B-4B5FC2CB6313@neustar.biz> <51B2283A.6070207@bbiw.net> <025FF36A-457A-4106-936C-7BDFC5ECA167@neustar.biz> <51B22C29.8010502@dcrocker.net> <51B231CE.7010908@dcrocker.net> <51B63552.3020607@cs.tcd.ie> <07DEB0E9-FB4B-4582-AE62-3673E52B6313@neustar.biz> <51B63E06.9040705@dcrocker.net> <9E8E21BE-2AD8-4239-8547-5BE543982CBD@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DB413@ex2k10mb2.corp.yaanatech.com> <208038CE-DD6B-4670-92CC-D91CFD770C52@cs.columbia.edu> <51B84A0D.1000702@cs.tcd.ie> <3B763E54-DE72-4855-A6AB-18E9A4DAC54F@oracle.com> <51B8AC31.3030608@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach - MITM X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 18:20:12 -0000 On Jun 12, 2013, at 1:13 PM, Stephen Farrell = wrote: > I guess bad-guy hacks my home router, then initiates a call from > or via there to me in my living room making it look like the call > comes from my bank. >=20 > If the key management was precisely the same as DKIM's then he'd > be able to feed me a public key to make it look like his signature > is ok for the bank's telephone number since I use my home router > for DNS as well. (Assuming my UA doesn't insist on DNSSEC.) Ahh, yeah I had kinda assumed that we weren't going to blindly trust DNS = on the public Internet, at least not for general behavior in whatever = RFC comes out of this work. (but in practice I would expect there to be = a lot of cases where just believing the DNS response's pub key info = would be fine and all that's actually done) -hadriel From jon.peterson@neustar.biz Wed Jun 12 11:23: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 20A0211E80E8 for ; Wed, 12 Jun 2013 11:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 46w0EEYG775q for ; Wed, 12 Jun 2013 11:23:10 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 253F011E80CC for ; Wed, 12 Jun 2013 11:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371061555; x=1686416367; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=dUi8IeYocs E0auLan1ezFnFAKdg/qOEWvS9f4E+oZws=; b=SGNNofIFrjyMAQZiOXOHxSRlsp /3fBo8BEsuzGs7RTLImcW2XzJXlsek1jiNhANlmXBWEi+KQDNHMejz9bhS6w== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25012062; Wed, 12 Jun 2013 14:25:54 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 14:22:50 -0400 From: "Peterson, Jon" To: Henning Schulzrinne , Dave Crocker Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgA== Date: Wed, 12 Jun 2013 18:22:50 +0000 Message-ID: In-Reply-To: <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hndCfVFqq5ICX69N7E6xWQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] current draft 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, 12 Jun 2013 18:23:14 -0000 Agreed. Though I do think that even for the domain model, we could get some value from looking at DANE to improve the way that credentials are managed. Whether we put the keys in the DNS or just point to the approved cert by reference, we should probably have some means for the successor to RFC4474 Identity-Info to tip off relying parties to DANE. But yes, for the telephone model it seems unlikely that casting these as domain names will get us very far. Jon Peterson Neustar, Inc. On 6/12/13 10:23 AM, "Henning Schulzrinne" wrote: >The simple semantics sounds similar to the RFC 4744 model for SIP URIs. >As discussed in various drafts, this model unfortunately doesn't work >well for the domain-less case, such as telephone numbers. > >On Jun 12, 2013, at 1:12 PM, Dave Crocker wrote: > >> On 6/12/2013 3:21 AM, Stephen Farrell wrote: >>> That's a fair point. However, I'd argue that the difference between >>> a DKIM-like and RPKI-like approach is far from just syntax. For >>> example, in an RPKI-like approach the callee has to verify who >>> delegated what to whom in order to check the signature (e.g. via >>> 5280 NameConstraints). With a DKIM-like approach, that's done in >>> some un- or differently-specified way by some infrastructure (before >>> making the public key available) and isn't directly visible to the >>> callee. That's definitely not just syntax I reckon. >>=20 >>=20 >> My simplistic description of the DKIM-like model is that the storage >>location constitutes the cert. >>=20 >> The semantic of the cert is "the owner of this location authorizes use >>of the key". Since the 'location' is a place in the DNS, the owner of >>the domain name at that location is validating use of the private key. >>=20 >> For very simple cert semantics like this, it works. Semantics that are >>more complex probably won't. >>=20 >> d/ >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 > From york@isoc.org Wed Jun 12 13:40: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 A47E121E804D for ; Wed, 12 Jun 2013 13:40: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 dW-sJzrDRbAg for ; Wed, 12 Jun 2013 13:40:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id B61FF11E80E7 for ; Wed, 12 Jun 2013 13:40:13 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 12 Jun 2013 20:40:12 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.130]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.15]) with mapi id 15.00.0702.005; Wed, 12 Jun 2013 20:40:12 +0000 From: Dan York To: "Peterson, Jon" , Henning Schulzrinne , Dave Crocker Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KA Date: Wed, 12 Jun 2013 20:40:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <646EE9253D64D242ABA7F881CC130E2F@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] current draft 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, 12 Jun 2013 20:40:23 -0000 On 6/12/13 2:22 PM, "Peterson, Jon" wrote: >Agreed. Though I do think that even for the domain model, we could get >some value from looking at DANE to improve the way that credentials are >managed. Whether we put the keys in the DNS or just point to the approved >cert by reference, we should probably have some means for the successor to >RFC4474 Identity-Info to tip off relying parties to DANE. Agreed (as you would expect me to say). I've been thinking about how DANE could help here, but... >But yes, for the telephone model it seems unlikely that casting these as >domain names will get us very far. ... I think this issue will get in the way right now. As much as I would love to see this as a good example of where DANE can help, I still haven't been able to wrap my brain around how we could use DNS for telephone numbers without running into all the exact same issues that made public ENUM non-deployable. :-( I agree, though, that it would be helpful to have some way for a header to alert relying parties to DANE in the event that there is a way it can work. Dan From hadriel.kaplan@oracle.com Wed Jun 12 14:41: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 DB8B121E808A for ; Wed, 12 Jun 2013 14:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 ISB3IBA8nGXQ for ; Wed, 12 Jun 2013 14:41:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E49D21E80F2 for ; Wed, 12 Jun 2013 14:41:03 -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 r5CLehQ4024495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 21:40:44 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 r5CLegLi024657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 21:40:42 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 r5CLefZL012323; Wed, 12 Jun 2013 21:40:41 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 14:38:57 -0700 MIME-Version: 1.0 Message-ID: Date: Wed, 12 Jun 2013 14:38:55 -0700 (PDT) From: Hadriel Kaplan To: Dan York References: In-Reply-To: X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Stephen Farrell , Dave Crocker , "Peterson, Jon" , Henning Schulzrinne Subject: Re: [stir] current draft 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, 12 Jun 2013 21:41:10 -0000 On Jun 12, 2013, at 4:40 PM, Dan York wrote: >> But yes, for the telephone model it seems unlikely that casting these = as >> domain names will get us very far. >=20 > ... I think this issue will get in the way right now. As much as I = would > love to see this as a good example of where DANE can help, I still = haven't > been able to wrap my brain around how we could use DNS for telephone > numbers without running into all the exact same issues that made = public > ENUM non-deployable. :-( That begs the question of what issues you think made Public ENUM fail, = and why we won't hit the same issues in whatever model we choose. -hadriel From dcrocker@bbiw.net Wed Jun 12 14:42: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 D89B721E80ED for ; Wed, 12 Jun 2013 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Qx3HkwBse4oU for ; Wed, 12 Jun 2013 14:42:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01E0321E8094 for ; Wed, 12 Jun 2013 14:42:22 -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 r5CLgIXC018782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Jun 2013 14:42:21 -0700 Message-ID: <51B8EB34.9030803@bbiw.net> Date: Wed, 12 Jun 2013 14:42:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 12 Jun 2013 14:42:22 -0700 (PDT) Subject: Re: [stir] current draft 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, 12 Jun 2013 21:42:30 -0000 On 6/12/2013 2:38 PM, Hadriel Kaplan wrote: > On Jun 12, 2013, at 4:40 PM, Dan York wrote: >> ... I think this issue will get in the way right now. As much as I would >> love to see this as a good example of where DANE can help, I still haven't >> been able to wrap my brain around how we could use DNS for telephone >> numbers without running into all the exact same issues that made public >> ENUM non-deployable. :-( > > That begs the question of what issues you think made Public ENUM fail, and why we won't hit the same issues in whatever model we choose. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Wed Jun 12 14:42: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 623FB21E80ED for ; Wed, 12 Jun 2013 14:42:50 -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 0Lhhs0nRvAqz for ; Wed, 12 Jun 2013 14:42:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71A9521E8094 for ; Wed, 12 Jun 2013 14:42:45 -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 r5CLggvl018801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Jun 2013 14:42:45 -0700 Message-ID: <51B8EB4C.8000308@dcrocker.net> Date: Wed, 12 Jun 2013 14:42:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 12 Jun 2013 14:42:45 -0700 (PDT) Subject: Re: [stir] current draft 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: Wed, 12 Jun 2013 21:42:50 -0000 On 6/12/2013 2:38 PM, Hadriel Kaplan wrote: > On Jun 12, 2013, at 4:40 PM, Dan York wrote: >> ... I think this issue will get in the way right now. As much as I would >> love to see this as a good example of where DANE can help, I still haven't >> been able to wrap my brain around how we could use DNS for telephone >> numbers without running into all the exact same issues that made public >> ENUM non-deployable. :-( > > That begs the question of what issues you think made Public ENUM fail, and why we won't hit the same issues in whatever model we choose. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pkyzivat@alum.mit.edu Wed Jun 12 15:01: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 7855021E812F for ; Wed, 12 Jun 2013 15:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, NORMAL_HTTP_TO_IP=0.001, 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 FUukeTeGH9MK for ; Wed, 12 Jun 2013 15:01:01 -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 2C9BE21E8111 for ; Wed, 12 Jun 2013 15:01:01 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id nP2P1l0080vyq2s57a10pa; Wed, 12 Jun 2013 22:01:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id na101l00j3ZTu2S3Ra10Q3; Wed, 12 Jun 2013 22:01:00 +0000 Message-ID: <51B8EF9B.9060503@alum.mit.edu> Date: Wed, 12 Jun 2013 18:00:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> In-Reply-To: <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@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=1371074460; bh=koKzQR7EhD5hYBzFIWmRypBAREBiUIqVFeGhp46MHFA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mjwgnd8t8i6fS6Ru0fYYLdjQNzk+9cVmD921+fM1scJKjSea2i5ZItDZpRD9Ka/O7 h2SVc0Z3SP2W+QAY3uxFFCSXFD/7pKL7EUgvPeZvpGGQm1YYfk/3vZSWItNUcrGpAp d71rAVIK1zlVAU5oEX8jHVuuPGrdt9u+1ajtgaGa0yJcbcQ85R8FdMCRXGrKpLJdTG kBQXZj95UJuzWtHiU+V18vB2dyfywy8il/LdjVSIggWnfgCYkiHvoTfmbLAsa9PkRf RLZYNlDBK5oTNen/jKnUeAH/Vva7Jova2KRiwAX8MdrSj2MCG8p8/ln4cUThzCsuiI tis15okJFUdaw== Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 22:01:05 -0000 On 6/11/13 12:54 PM, Hadriel Kaplan wrote: > > On Jun 11, 2013, at 10:45 AM, Stephen Farrell wrote: > >> I'm also confused as to why its a non-starter to have a >> public database of public keys and phone numbers, but is ok >> that anyone can build that database themselves, with fairly >> modest effort. That seems odd to me anyway. (To be clear, >> I do consider de-referencing a URL for a public key or >> cert as a DB-lookup.) > > If the mechanism uses a URL for de-referencing, then the structure of the URL does not need to follow phone numbers in any way. So you couldn't try to harvest them. E.g., I call from +1-212-555-1212 and I sign it and in the SIP INVITE I tell you to go get the cert from: > > http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb > > The cert you download says it's for "+1-212-555-1212" (e.g., in the SAN field or something), and it's issuer is NANPA (North American Numbering Plan Administration), which you presumably have locally known root cert for and acceptance as a trusted CA. > > So yes if you received the call from +1-212-555-1212 you'd know it's an AT&T number (because of the URL's domain), I see no reason why the URL needs to mention att. It could be an IP address, frequently changed. Or the certs could be hosted by an intermediary for retrieval. Thanks, Paul > but you wouldn't be able to figure out what other numbers AT&T has - only those that called you. > > Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" follows a schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org". You don't even need to receive a call. Just start querying all possible digits of the fixed length/depth. For the 212 area code there are only 10 million possible numbers. Even for all of the US it's only around a couple billion, because most area codes haven't been allocated, and the list of which ones have is public: > http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_codes > > -hadriel > p.s. the above is not to say I think using HTTP is the right answer - you can do the same thing with other database query protocols. The point is the query key need not follow any number-based or well-known schema. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From jon.peterson@neustar.biz Wed Jun 12 15: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 4C1DF21E812E for ; Wed, 12 Jun 2013 15:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 bjKJM9k0-Fvb for ; Wed, 12 Jun 2013 15:01:31 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8D121E8128 for ; Wed, 12 Jun 2013 15:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371074423; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Cr3Jjxdp5i zCP6X0vXSAQVgho5zfdy6G+/EfSvAVK9c=; b=mrz6yIxzBD0o7N89cE+6LZZQLC /njOFbUj4LykKvcKyVcel1p2xjEn0fZdbUEhPNf8oi17yMk1pc18FX8KJzTA== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20895648; Wed, 12 Jun 2013 18:00:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 18:01:11 -0400 From: "Peterson, Jon" To: Dave Crocker , "stir@ietf.org" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IA Date: Wed, 12 Jun 2013 22:01:10 +0000 Message-ID: In-Reply-To: <51B8EB34.9030803@bbiw.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NMd+tamGO4wWlFhvSE3LJg== Content-Type: text/plain; charset="us-ascii" Content-ID: <313B7E71F6224F4B930821F8DD053537@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] current draft 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, 12 Jun 2013 22:01:35 -0000 It's always hard to say with any certainty why something failed. We can point to various causes and effects, one of which in this case certainly would be the difficulty of getting every world government to implement the system. ENUM was also designed from the start to empower end users to control how their numbers would be associated with Internet services, yet because of its built-in regulatory structures it required that empowerment to be driven by carriers with different interests. But we don't even have to be asking ourselves about the relevance of public ENUM to the proposed work here in STIR unless we want to try to base everything on keying in the public DNS for telephone numbers. There are other models for this that don't have the liabilities I described above, anyway. Keying in private DNS is more viable, for example. I think a PKI is more viable. Securing the origin of calls is a different problem than providing a global routing directory, and we'd be wise not to muddle them together. Jon Peterson Neustar, Inc. On 6/12/13 2:42 PM, "Dave Crocker" wrote: >On 6/12/2013 2:38 PM, Hadriel Kaplan wrote: >> On Jun 12, 2013, at 4:40 PM, Dan York wrote: >>> ... I think this issue will get in the way right now. As much as I >>>would >>> love to see this as a good example of where DANE can help, I still >>>haven't >>> been able to wrap my brain around how we could use DNS for telephone >>> numbers without running into all the exact same issues that made public >>> ENUM non-deployable. :-( >> >> That begs the question of what issues you think made Public ENUM fail, >>and why we won't hit the same issues in whatever model we choose. > > >+1 > > >d/ > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Wed Jun 12 15:02: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 0E98E21E8128 for ; Wed, 12 Jun 2013 15:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.386 X-Spam-Level: X-Spam-Status: No, score=-100.386 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 6IUr8e9waAN3 for ; Wed, 12 Jun 2013 15:02:38 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 690E121E8135 for ; Wed, 12 Jun 2013 15:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=gpKq/+RPCKfI+RFdp9dDHk4DdLm/SLekMmF6rWfOJhc=; b=AGrtBkTomIWqvJaFCEOuSfnfmUuMAHsHym563mGDrMNNsWMaFVF0+LCEfi6+6/Ejx89dRtJXeekswhVA2vzmFVjqQqX62a+n8WxCYkuec8gwSaWoJifnx9hI8d/dNEQFbT/y0vC6VHBy4WPghZW5IyImt0As1JLsM5hm1HchpPg=; Received: from neustargw.va.neustar.com ([209.173.53.233]:36954 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Umt7j-00085e-Gs; Wed, 12 Jun 2013 18:02:35 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <51B8EB34.9030803@bbiw.net> Date: Wed, 12 Jun 2013 18:02:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net> References: <51B8EB34.9030803@bbiw.net> To: Dave Crocker X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 12 Jun 2013 22:02:42 -0000 1. the "global root" problem - who owns and manages e164.arpa, and what = are the rules? 2. It took action by the regulator before anything happened. Because = many regulators didn't understand what this thing was, and still don't, = they didn't act 3. It took a level of cooperation between service providers who owned = parts of the hierarchy that could not be gained 4. Any public database that was able to show any information about a = telephone number was considered a privacy issue, requiring a lot of = "sign off", which never happened.=20 5. Everyone objected to being able to determine what numbers were "live" 6. Carriers objected to a public database that told competitors what = numbers they controlled 7. The DNS query was a poor fit for the problem - what evolved was a SIP = redirect interface because no vendors liked the DNS interface 8. Delegation of numbers don't fit a tree model any more 9. URIs and other things you put in the DNS were insufficient for the = problem 10. Other databases for the problems existed, and it was easier to use = them, mostly because they existed. These are non-public databases As Rich Shockey notes, there is a fair amount of "ENUM" deployment = inside carriers, although it's a SIP redirect interface. The underlying = data structures are the same as ENUM. Actually, it's only the = interfaces for provisioning that are the same. No one ever does a DNS = query. If we want this deployed soon, it's my considered opinion you can't have = a public per-TN database. We learned in ENUM that DNS is not a good fit for a telephone number. = We understand it looks attractive, but it doesn't fit, primarily because = the tree doesn't reflect the delegation model, and a complete tree out = to each individual TN is not really a practical solution. Delegations = are ranges. DNS doesn't do ranges. Delegations have port-out issues, = which DNS doesn't do unless you populate the whole tree. It's a bad = fit. The DNS guys, at the time, kept asking us "do the limitations of DNS = work for you"? We kept believing, and saying yes. I now understand why = they kept asking the same damn question over and over. The limitations = do not work for us. My company has built ENUM based systems. We continuously trip over the = mismatch between the DNS model and the problem. We fix it by ignoring = the DNS model, building a database that matches the actual delegation = model and treating the DNS query as an awkward, but solvable interface = issue. And it still bites us on things like UDP (very bad for DDoS = security) and the restrictions on what a NAPTR can do. Brian On Jun 12, 2013, at 5:42 PM, Dave Crocker wrote: > On 6/12/2013 2:38 PM, Hadriel Kaplan wrote: >> On Jun 12, 2013, at 4:40 PM, Dan York wrote: >>> ... I think this issue will get in the way right now. As much as I = would >>> love to see this as a good example of where DANE can help, I still = haven't >>> been able to wrap my brain around how we could use DNS for telephone >>> numbers without running into all the exact same issues that made = public >>> ENUM non-deployable. :-( >>=20 >> That begs the question of what issues you think made Public ENUM = fail, and why we won't hit the same issues in whatever model we choose. >=20 >=20 > +1 >=20 >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Wed Jun 12 15:16: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 A35A621F99C2 for ; Wed, 12 Jun 2013 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.253 X-Spam-Level: X-Spam-Status: No, score=-106.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_24=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 OCGBpKeljKIq for ; Wed, 12 Jun 2013 15:16:49 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5F52921F99B7 for ; Wed, 12 Jun 2013 15:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371075580; x=1686430996; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=eQASzU9gk4 hZtTdJZx72NytA7b6KCgyyFik2bZSHgeo=; b=qYV0WKUrctwSZ51mDxlMUTy0+b M5cLWFT6wcRgKHTyQ2XDoASB6JaMVYIhf9K3oBH9ayvuvFIiuW90klqA7/bQ== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25024995; Wed, 12 Jun 2013 18:19:39 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 18:16:35 -0400 From: "Peterson, Jon" To: "PFAUTZ, PENN L" , Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] DKIM-like key mgmt approach Thread-Index: AQHOZh8S2oJeIJpUPE6dFgwNpMeOBpkvvy4AgADR7ACAADY6gIAAFCKAgAAkGACAAB+6gIAAEHgAgAADlACAABqlAIAA+rOAgAAtxQA= Date: Wed, 12 Jun 2013 22:16:34 +0000 Message-ID: In-Reply-To: <38726EDA2109264987B45E29E758C4D604857FED@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VwztKgQ1+s9urmQyig+faQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 22:16:53 -0000 Agreed that it is better to work from the nation level up than to try to trickle this down from a global root. There are technologies (like LoST, used in ECRIT) that are designed to have allow a more opt-in structure for navigating between trees like this. Perhaps we could look into technology like that to help us figure out the right way to work this. Jon Peterson Neustar, Inc. On 6/12/13 5:32 AM, "PFAUTZ, PENN L" wrote: >I think Hadriel is on the right track. As to the globalization issue, my >takeaway from efforts to build an authoritative global enum tree is that >you will need to work from national authorities up. If you get per >country data sources it will not be hard to link them together/interwork. >This approach also provides some national flexibility. > >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 >Hadriel Kaplan >Sent: Tuesday, June 11, 2013 5:35 PM >To: Brian Rosen >Cc: stir@ietf.org; Henning Schulzrinne >Subject: Re: [stir] DKIM-like key mgmt approach > > >On Jun 11, 2013, at 4:00 PM, Brian Rosen wrote: > >> If you put in in public enum, you have all of the problems of managing >>the tree that eluded us. As a practical matter, you get carriers to pay >>a third party database company to manage the +1 tree, a la cc1enum. > >Not necessarily. For each country code, you make their numbering plan >admin the authority. For example for +1, you make NANPA the authority >(or maybe NANC or whatever it needs to be). They're "responsible" for >generating a unique key pair for each +1 E.164 signed by their root cert, >giving the key pair to the org they give the number to, and hosting the >pub key for each in a DNS structure. > >Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN >doesn't do the work for DNS. NANPA contracts with someone else to do it, >like Neustar (which as far as I know runs NANPA). Since they're doing it >all in bulk, then the per number entry it shouldn't cost anywhere near >what normal domain name registrations do. NANPA gets the money for it >from the E.164 number allocation fee, annual maintenance fee, and change >fee or whatever. > >I'm not saying getting this done is easy - it's NOT - but nothing we do >is going to be. At least this way there's only one organization to deal >with to get the cert-db part done, per country. > > >> In the U.S., it could be NPAC that held the per-TN data. It already >>does for most numbers. Having NPAC provide an ENUM query in e164.arpa >>is certainly possible, but I think would be an enormous effort to get >>approved. Having it supply a query to SPs based on a sane query >>protocol like a web service would be better and much easier to get >>fielded. Way too much baggage in ENUM I think. > >But the NPAC only holds data for NANP-based numbers. How does a US >carrier authenticate a number from the UK or Germany or wherever? > >-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 stephen.farrell@cs.tcd.ie Wed Jun 12 15:18: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 6558621F99B7 for ; Wed, 12 Jun 2013 15:18:04 -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 A87JShb8hRvn for ; Wed, 12 Jun 2013 15:17:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F131121F99BE for ; Wed, 12 Jun 2013 15:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA0CBBE80; Wed, 12 Jun 2013 23:17:30 +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 bFj3OT5eb2Vu; Wed, 12 Jun 2013 23:17:30 +0100 (IST) Received: from [10.87.48.12] (unknown [86.41.52.50]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2601ABE5C; Wed, 12 Jun 2013 23:17:30 +0100 (IST) Message-ID: <51B8F379.7080901@cs.tcd.ie> Date: Wed, 12 Jun 2013 23:17:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <51B6F9AC.1040806@cs.tcd.ie> <829C653E-48A7-4BA5-A61C-60D1E27EF8DA@neustar.biz> <51B7380D.1020706@cs.tcd.ie> <5C277FC7-6203-4C47-8FA8-C92BD92DE8D4@oracle.com> <51B8EF9B.9060503@alum.mit.edu> In-Reply-To: <51B8EF9B.9060503@alum.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stir@ietf.org Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 12 Jun 2013 22:18:04 -0000 On 06/12/2013 11:00 PM, Paul Kyzivat wrote: >> >> So yes if you received the call from +1-212-555-1212 you'd know it's >> an AT&T number (because of the URL's domain), > > I see no reason why the URL needs to mention att. > It could be an IP address, frequently changed. > Or the certs could be hosted by an intermediary for retrieval. Doesn't matter. Using certs the relationships are crystal clear as an inherent part of certificate validation. If you want to change that you'd need to re-invent a *lot* of PKI stuff. S. From hadriel.kaplan@oracle.com Wed Jun 12 15:52: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 8F3B611E8101 for ; Wed, 12 Jun 2013 15:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_34=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 rEQwYum7p0er for ; Wed, 12 Jun 2013 15:51:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1524621F994E for ; Wed, 12 Jun 2013 15:51:51 -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 r5CMphlD025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 22:51:44 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 r5CMpgfO012994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 22:51:42 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 r5CMpf7r005071; Wed, 12 Jun 2013 22:51:41 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 15:51: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: <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net> Date: Wed, 12 Jun 2013 18:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <984AC1B1-0AEB-41BA-8DB8-1685D9A7E894@oracle.com> References: <51B8EB34.9030803@bbiw.net> <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] current draft 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, 12 Jun 2013 22:52:03 -0000 Before I respond to your points below in a separate email, I think we = might be talking past each other somewhat... When I say "we might be able to use an ENUM model", I certainly don't = mean populating the e164.arpa subtree with NAPTRs of SIP URIs. I mean populating a new DNS subtree, say cid.arpa or whatever, with = cert/pub-key information records (e.g. a CERT Resource Record or = whatever), but based on the same reverse-number-dotted-notation for the = domain name "key" as described in ENUM. This new subtree would be = purely for the purposes of caller-id verification, not routing. In a perfect world, IANA would delegate the authority/owner of .cid.arpa = to be the ITU, and the ITU would delegate .1.cid.arpa to NANPA and = .4.4.cid.arpa to OFCOM and .9.4.cid.arpa to the Bundesnetzagentur and so = on.=20 Nor would I call it "ENUM" at all in any document whatsoever, just to = avoid this type of confusion and stigma. It just seemed like a = convenient way to describe it in this email list discussion so far. -hadriel On Jun 12, 2013, at 6:02 PM, Brian Rosen wrote: > 1. the "global root" problem - who owns and manages e164.arpa, and = what are the rules? > 2. It took action by the regulator before anything happened. Because = many regulators didn't understand what this thing was, and still don't, = they didn't act > 3. It took a level of cooperation between service providers who owned = parts of the hierarchy that could not be gained > 4. Any public database that was able to show any information about a = telephone number was considered a privacy issue, requiring a lot of = "sign off", which never happened.=20 > 5. Everyone objected to being able to determine what numbers were = "live" > 6. Carriers objected to a public database that told competitors what = numbers they controlled > 7. The DNS query was a poor fit for the problem - what evolved was a = SIP redirect interface because no vendors liked the DNS interface > 8. Delegation of numbers don't fit a tree model any more > 9. URIs and other things you put in the DNS were insufficient for the = problem > 10. Other databases for the problems existed, and it was easier to use = them, mostly because they existed. These are non-public databases >=20 > As Rich Shockey notes, there is a fair amount of "ENUM" deployment = inside carriers, although it's a SIP redirect interface. The underlying = data structures are the same as ENUM. Actually, it's only the = interfaces for provisioning that are the same. No one ever does a DNS = query. >=20 > If we want this deployed soon, it's my considered opinion you can't = have a public per-TN database. >=20 > We learned in ENUM that DNS is not a good fit for a telephone number. = We understand it looks attractive, but it doesn't fit, primarily because = the tree doesn't reflect the delegation model, and a complete tree out = to each individual TN is not really a practical solution. Delegations = are ranges. DNS doesn't do ranges. Delegations have port-out issues, = which DNS doesn't do unless you populate the whole tree. It's a bad = fit. >=20 > The DNS guys, at the time, kept asking us "do the limitations of DNS = work for you"? We kept believing, and saying yes. I now understand why = they kept asking the same damn question over and over. The limitations = do not work for us. >=20 > My company has built ENUM based systems. We continuously trip over = the mismatch between the DNS model and the problem. We fix it by = ignoring the DNS model, building a database that matches the actual = delegation model and treating the DNS query as an awkward, but solvable = interface issue. And it still bites us on things like UDP (very bad for = DDoS security) and the restrictions on what a NAPTR can do. >=20 > Brian >=20 From jon.peterson@neustar.biz Wed Jun 12 16:46: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 5AA1111E8114 for ; Wed, 12 Jun 2013 16:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_34=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 u1tyvO00yhDp for ; Wed, 12 Jun 2013 16:46:30 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4836F11E8119 for ; Wed, 12 Jun 2013 16:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371080956; x=1686436164; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=zGegenP72m 1txvh5Bi9Yl/1zeduwyg8+FBSPNlnGSfM=; b=Kb4cXg4mWrAHU7PXb6gl44+MzT aCtrUqXebHI207HThoO/zkIPJ2HON/J9KnbgImJbq5qXvEvqQnemXcHOM1JA== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25027593; Wed, 12 Jun 2013 19:49:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 19:46:12 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAIAABbCAgAANuID//5nhgA== Date: Wed, 12 Jun 2013 23:46:12 +0000 Message-ID: In-Reply-To: <984AC1B1-0AEB-41BA-8DB8-1685D9A7E894@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uX1cDqgtCp3aMQS2DQbIMw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] current draft 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, 12 Jun 2013 23:46:34 -0000 This is indeed how, ten years ago, we originally imagined RFC4474 would handle telephone numbers, whether we fancied it would be in e164.arpa or elsewhere. Part of what is different about the STIR proposal is that it explores a more chaotic approach to authority in the hopes of seeding adoption. The proposed STIR charter outlines two ways to secure identity: an in-band and an out-of-band approach. Discussion so far on this list has focused largely on the in-band. For the out-of-band approach, we need to be able to explore credentials whose authority rests on some other means than delegation from on high: perhaps, like in ViPR, from probing how numbers are routed and using this to prove possession of the number. Ideally, the credentials used in the two prongs should be compatible (the charter text says that, anyway). For example, it would be great if, at the start of an adoption curve, a savvy end user could acquire a credential through proving SMS return routability, say, which is stored in the user's smart phone and from there used to secure communications - then later, when the user's service provider implements this system, they could sign that same credential to allow its use in more contexts. So could DNS protocols play a role in a system with those properties? They could, in some places. I certainly wouldn't rule it out. But arguing from what the ITU or IANA would delegate doesn't have much relevance to the out-of-band dimension here. One of the differences between PKI as it has been implemented for the web (with all its warts) and the DNS is that the CAs can rely on enrollment methods that don't assume a secure chain of delegation. That strikes me as analogous to our situation in the out-of-band prong here. Jon Peterson Neustar, Inc. On 6/12/13 3:51 PM, "Hadriel Kaplan" wrote: >Before I respond to your points below in a separate email, I think we >might be talking past each other somewhat... > >When I say "we might be able to use an ENUM model", I certainly don't >mean populating the e164.arpa subtree with NAPTRs of SIP URIs. > >I mean populating a new DNS subtree, say cid.arpa or whatever, with >cert/pub-key information records (e.g. a CERT Resource Record or >whatever), but based on the same reverse-number-dotted-notation for the >domain name "key" as described in ENUM. This new subtree would be purely >for the purposes of caller-id verification, not routing. > >In a perfect world, IANA would delegate the authority/owner of .cid.arpa >to be the ITU, and the ITU would delegate .1.cid.arpa to NANPA and >.4.4.cid.arpa to OFCOM and .9.4.cid.arpa to the Bundesnetzagentur and so >on.=20 > >Nor would I call it "ENUM" at all in any document whatsoever, just to >avoid this type of confusion and stigma. It just seemed like a >convenient way to describe it in this email list discussion so far. > >-hadriel > > >On Jun 12, 2013, at 6:02 PM, Brian Rosen wrote: > >> 1. the "global root" problem - who owns and manages e164.arpa, and what >>are the rules? >> 2. It took action by the regulator before anything happened. Because >>many regulators didn't understand what this thing was, and still don't, >>they didn't act >> 3. It took a level of cooperation between service providers who owned >>parts of the hierarchy that could not be gained >> 4. Any public database that was able to show any information about a >>telephone number was considered a privacy issue, requiring a lot of >>"sign off", which never happened. >> 5. Everyone objected to being able to determine what numbers were "live" >> 6. Carriers objected to a public database that told competitors what >>numbers they controlled >> 7. The DNS query was a poor fit for the problem - what evolved was a >>SIP redirect interface because no vendors liked the DNS interface >> 8. Delegation of numbers don't fit a tree model any more >> 9. URIs and other things you put in the DNS were insufficient for the >>problem >> 10. Other databases for the problems existed, and it was easier to use >>them, mostly because they existed. These are non-public databases >>=20 >> As Rich Shockey notes, there is a fair amount of "ENUM" deployment >>inside carriers, although it's a SIP redirect interface. The underlying >>data structures are the same as ENUM. Actually, it's only the >>interfaces for provisioning that are the same. No one ever does a DNS >>query. >>=20 >> If we want this deployed soon, it's my considered opinion you can't >>have a public per-TN database. >>=20 >> We learned in ENUM that DNS is not a good fit for a telephone number. >>We understand it looks attractive, but it doesn't fit, primarily because >>the tree doesn't reflect the delegation model, and a complete tree out >>to each individual TN is not really a practical solution. Delegations >>are ranges. DNS doesn't do ranges. Delegations have port-out issues, >>which DNS doesn't do unless you populate the whole tree. It's a bad fit. >>=20 >> The DNS guys, at the time, kept asking us "do the limitations of DNS >>work for you"? We kept believing, and saying yes. I now understand why >>they kept asking the same damn question over and over. The limitations >>do not work for us. >>=20 >> My company has built ENUM based systems. We continuously trip over the >>mismatch between the DNS model and the problem. We fix it by ignoring >>the DNS model, building a database that matches the actual delegation >>model and treating the DNS query as an awkward, but solvable interface >>issue. And it still bites us on things like UDP (very bad for DDoS >>security) and the restrictions on what a NAPTR can do. >>=20 >> Brian >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Wed Jun 12 17:50: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 9877221E8088 for ; Wed, 12 Jun 2013 17:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_34=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 wmGp1JQzYS5j for ; Wed, 12 Jun 2013 17:50:48 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2973321E805A for ; Wed, 12 Jun 2013 17:50:48 -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 r5D0ofSW010955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 00:50: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 r5D0od5r020630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 00:50:40 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5D0odGt008174; Thu, 13 Jun 2013 00:50:39 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 17:50:19 -0700 MIME-Version: 1.0 Message-ID: Date: Wed, 12 Jun 2013 17:50:17 -0700 (PDT) From: Hadriel Kaplan To: Brian Rosen References: <51B8EB34.9030803@bbiw.net> <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net> In-Reply-To: <78385DAF-D8C1-40AC-B996-BCFA01444CD5@brianrosen.net> X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] current draft 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, 13 Jun 2013 00:50:56 -0000 On Jun 12, 2013, at 6:02 PM, Brian Rosen wrote: > 1. the "global root" problem - who owns and manages e164.arpa, and = what are the rules? We're not talking about e164.arpa per se, but let's assume cid.arpa: the = owner of cid.arpa in theory should be the ITU, and they should delegate = the country-code subdomains to the respective country number admin = authorities (a list that is relatively small and very static). In = practice, however, we might be able to get away with having IANA just do = it directly to the country admin authorities. The actual *work* of = administration and running servers wouldn't be done by them, but rather = contracted out. > 2. It took action by the regulator before anything happened. Because = many regulators didn't understand what this thing was, and still don't, = they didn't act > 3. It took a level of cooperation between service providers who owned = parts of the hierarchy that could not be gained The reason for both those above issues is the same: because there was = nothing to gain by the stakeholders. A Public ENUM wouldn't do anything = new for carriers, just cause headaches. It wouldn't even benefit = consumers. It was a solution looking for a problem. If, on the other hand, we think caller-id validation is a real problem = for service providers themselves, that either they themselves recognize = and want to fix or the regulators force them to recognize and fix, then = that's a very different ballgame. As long as the solution doesn't = disrupt their business models and operations overhead. > 4. Any public database that was able to show any information about a = telephone number was considered a privacy issue, requiring a lot of = "sign off", which never happened.=20 > 5. Everyone objected to being able to determine what numbers were = "live" > 6. Carriers objected to a public database that told competitors what = numbers they controlled Agreed, the above are real problems. But it's not clear if they apply = to E.164 signature keys. #4 and #5 are easy to avoid... #6 not so much. = I can't quite figure out how to avoid #6. :( (I'll skip #7 and move it to later) > 8. Delegation of numbers don't fit a tree model any more Agreed, but we don't need to delegate anything out to anyone. The = subdomain authority could remain with the country number admins for ALL = their numbers. For example, all country-code-44 number certs in the DNS = records could be issued by OFCOM as the CA, not by the UK carriers. The = UK carriers would do the signing, because OFCOM would give them the priv = keys for their numbers. > 9. URIs and other things you put in the DNS were insufficient for the = problem Actually people have fit a crap-load of stuff into ENUM NAPTR URIs, but = we're not talking about NAPTR nor URIs for this new thing anyway. > 10. Other databases for the problems existed, and it was easier to use = them, mostly because they existed. These are non-public databases Yup, existing deployment invariably trumps something new if the = something new doesn't provide new = capabilities/features/revenue/cost-savings. But I don't know of an = existing caller-id verification database. There are existing = caller-name databases of course, but that's different. And the ENUM ones are non-public because the data itself is (1) private = and (2) not usable in a public context. The entries in the database = (the results of the lookup) aren't meaningful to anyone but the carrier = asking the query. That doesn't apply for caller-id keys. > 7. The DNS query was a poor fit for the problem - what evolved was a = SIP redirect interface because no vendors liked the DNS interface >=20 > As Rich Shockey notes, there is a fair amount of "ENUM" deployment = inside carriers, although it's a SIP redirect interface. The underlying = data structures are the same as ENUM. Actually, it's only the = interfaces for provisioning that are the same. No one ever does a DNS = query. I think you and I live in different worlds. Perhaps you never see ENUM = being used because maybe it doesn't reach Neustar's services? In my = world, ENUM gets used a LOT. If you run Wireshark inside the carrier on = the right links/subnets, you'll see constant DNS queries for NAPTRs = using reverse-number-dotted domain-name format for the query key. It's = not SIP Redirect, it's actual DNS over UDP packets. But it never leaves = the carrier's private network. It's generated by proxies, gateways, and = SBCs as clients, to databases. And speaking for one vendor, we like it = way more than SIP Redirect (which we also support); and apparently so do = some of our big customers. It has some real benefits. > If we want this deployed soon, it's my considered opinion you can't = have a public per-TN database. Of course, it's always faster/easier to deploy something in private = contexts at the start. If we go with a Public-Internet DNS-based model = as the ultimate goal/solution, for example: one could start earlier with = the data for some subset of numbers, on servers run by Neustar or = whomever, only accessible by members "in-the-club". I.e., similar to a = private or carrier ENUM model. -hadriel From dhc2@dcrocker.net Wed Jun 12 21:01: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 9B7EB21F894E for ; Wed, 12 Jun 2013 21:01:39 -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 tB4uWiON1ioH for ; Wed, 12 Jun 2013 21:01:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8056E21F9949 for ; Wed, 12 Jun 2013 21:01:34 -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 r5D41RUW024152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 21:01:30 -0700 Message-ID: <51B94411.3090502@dcrocker.net> Date: Wed, 12 Jun 2013 21:01:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 12 Jun 2013 21:01:30 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 13 Jun 2013 04:01:47 -0000 On 6/12/2013 3:01 PM, Peterson, Jon wrote: > But we don't even have to be asking ourselves about the relevance of > public ENUM to the proposed work here in STIR unless we want to try to > base everything on keying in the public DNS for telephone numbers. There > are other models for this that don't have the liabilities I described > above, anyway. Keying in private DNS is more viable, for example. I think > a PKI is more viable. Other models? Is there a written description of the integrated query service that you folks are considering, in terms of design, administration and operation? It would help to also hear where such a design has already been successfully deployed. As the Enum experience showed, schemes can be intelligent and appealing but not succeed. So for any new deployment, any analysis needs to start with skepticism and work its way up with pragmatics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Jun 12 21:43: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 1F22421E804D for ; Wed, 12 Jun 2013 21:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 1QFxbgWvO0Aw for ; Wed, 12 Jun 2013 21:42:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29611E80BA for ; Wed, 12 Jun 2013 21:42:54 -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 r5D4gl5Z018379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 04:42:48 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 r5D4gmof010372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 04:42:49 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 r5D4gmsV011068; Thu, 13 Jun 2013 04:42:48 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-151-252.vpn.oracle.com (/10.154.151.252) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 21:42:48 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 13 Jun 2013 00:42:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] current draft 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, 13 Jun 2013 04:43:01 -0000 On Jun 12, 2013, at 6:01 PM, "Peterson, Jon" = wrote: > It's always hard to say with any certainty why something failed. We = can > point to various causes and effects, one of which in this case = certainly > would be the difficulty of getting every world government to implement = the > system. ENUM was also designed from the start to empower end users to > control how their numbers would be associated with Internet services, = yet > because of its built-in regulatory structures it required that = empowerment > to be driven by carriers with different interests. >=20 > But we don't even have to be asking ourselves about the relevance of > public ENUM to the proposed work here in STIR unless we want to try to > base everything on keying in the public DNS for telephone numbers. = There > are other models for this that don't have the liabilities I described > above, anyway. The liability you described above for ENUM is the same liability for = caller-id: we need the carriers to agree to do this. We don't need = *all* of them to, at least not at the start, but we need a critical mass = within at least one country, preferably more than one country. = Convincing just Enterprises to do it is neither necessary nor = sufficient. > Keying in private DNS is more viable, for example. I think > a PKI is more viable. In what way is DNS with DNSSEC/DANE *not* a PKI? -hadriel From hadriel.kaplan@oracle.com Wed Jun 12 22:29: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 3537E21F99DE for ; Wed, 12 Jun 2013 22:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 KGUF76RKxPuU for ; Wed, 12 Jun 2013 22:29:12 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CE34521F99CF for ; Wed, 12 Jun 2013 22:29: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 r5D5TBjq006119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 05:29:12 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 r5D5TABS007766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 05:29:10 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 r5D5TAHQ027869; Thu, 13 Jun 2013 05:29:10 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-151-252.vpn.oracle.com (/10.154.151.252) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 22:29: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: Date: Thu, 13 Jun 2013 01:29:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <633497AC-D5D5-4AC6-BC4E-9AE5122F8BA1@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] stir input drafts X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 13 Jun 2013 05:29:18 -0000 On Jun 11, 2013, at 10:17 PM, "Peterson, Jon" = wrote: > However, based on all of our prior discussions we knew that there were = use > cases where no amount of refining RFC4474 was going to help. Pretty = much > any use case that transited a PSTN gateway necessarily would need > something different. We therefore started sketching out some strawmen = for > how we could attack that part of the problem by creating an = out-of-band > connection of some kind, without resorting the DHT of ViPR. EKR came = up > with a model for this that had less security problems than what I was > thinking of, which is documented here: > = https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-callerid-fal= l > back.txt One nice thing about the Call Detail Service idea is the Call Detail = database already exists, for US-based calls. It's at something like: calls.prism.nsa.gov Unfortunately they probably won't let us access it for caller-id = verification. But on a more serious note, I mentioned this at the meeting in DC but = I'll repeat it for posterity: the really useful property of a CDS model, = or potentially other models that don't rely on the signaling to carry = anything, is that once a calling party opts-in to the idea, they prevent = anyone else from spoofing them so long as the called party verifies. By = that I mean you can know when a received call's caller-id *must* be = verifiable, and thus be able to reject it if it's not. For example the = instant Fidelity joins such a model for their outbound calls, no one = else can spoof their numbers, because no matter how their call got to = you, as soon as you check the CDS you'll know if it's legit or being = spoofed. As opposed to any in-band method (4474, p-asserter signing, etc.), where = you can only know a caller-id is valid if and only if the received = signaling has whatever new headers we define. So when you receive a = call claiming to be from Fidelity, but it has no such headers, you don't = know if it doesn't have the headers because the call is fraudulent, or = just Fidelity isn't doing this new thing yet, or just the call came = through some PRI circuit in the middle somewhere. So it's very useful for overcoming the typical early adoption problem. If we use an in-band method with a DNSSEC/DANE-type model, regardless of = whether we get the new headers or not we can get the property of knowing = whether Fidelity is doing this new thing or not yet; but we still don't = know if the headers just got lost in translation. (huh, there's a triple = pun there for old bell-heads) -hadriel From york@isoc.org Thu Jun 13 05: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 4270321F9A5B for ; Thu, 13 Jun 2013 05:51:50 -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 HOzog6DycL+W for ; Thu, 13 Jun 2013 05:51:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1853321F96D9 for ; Thu, 13 Jun 2013 05:51:46 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB071.namprd06.prod.outlook.com (10.242.211.15) with Microsoft SMTP Server (TLS) id 15.0.702.21; Thu, 13 Jun 2013 12:51:36 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Thu, 13 Jun 2013 12:51:35 +0000 From: Dan York To: Hadriel Kaplan Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KAgABTd4CAALvxgA== Date: Thu, 13 Jun 2013 12:51:35 +0000 Message-ID: In-Reply-To: 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-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB071; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Stephen Farrell , Dave Crocker , "Peterson, Jon" , Henning Schulzrinne Subject: Re: [stir] current draft 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, 13 Jun 2013 12:51:50 -0000 Hadriel, On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >That begs the question of what issues you think made Public ENUM fail, >and why we won't hit the same issues in whatever model we choose. Since you addressed this question to me, I feel compelled to answer... but in the meantime both Brian and Jon have given much more detailed answers with which I mostly agree. I saw security/privacy issues as the main issues that made Public ENUM not work, i.e. Brian's points 4, 5 and 6: > 4. Any public database that was able to show any information about a >telephone number was considered a privacy issue, requiring a lot of "sign >off", which never happened. > 5. Everyone objected to being able to determine what numbers were "live" > 6. Carriers objected to a public database that told competitors what >numbers they controlled The potential for spam was also high. Five or six years ago there was at least one tool circulating around that would walk an ENUM tree, generate a list of all potential phone numbers and then send SIP INVITEs to all of those numbers. I remember either seeing a video or reading about how someone did this with all the public ENUM numbers published for Germany (at that time). So using Public ENUM could be a fantastic way to potentially get yourself on the calling lists for telemarketers. Ideally, I think a public service *would* be a useful way to enable ubiquitous usage. I'm just not sure how to get there without also opening a solution up to these same kind of security/privacy issues. Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ From chris_wendt@cable.comcast.com Thu Jun 13 06:38: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 18E2421F9AED for ; Thu, 13 Jun 2013 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 Ve509nB3S0sF for ; Thu, 13 Jun 2013 06:37:59 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4377E21F9AC4 for ; Thu, 13 Jun 2013 06:37:59 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.77056077; Thu, 13 Jun 2013 07:37:25 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Jun 2013 09:37:33 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.49]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Thu, 13 Jun 2013 09:37:33 -0400 From: "Wendt, Chris" To: Dan York Thread-Topic: [stir] current draft charter Thread-Index: AQHOaDsmzzxiRhKUq0SNP5wemGrczQ== Date: Thu, 13 Jun 2013 13:37:31 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peterson, Jon" , Hadriel Kaplan , "stir@ietf.org" , Dave Crocker , Stephen Farrell , Henning Schulzrinne Subject: Re: [stir] current draft 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, 13 Jun 2013 13:38:04 -0000 Hi Folks, I believe it couldn't be a better time to start discussing public routing. = While this is a little beyond the scope of protecting caller-id, I think t= he effort is highly complimentary, and solving both together will provide a= better path to get things implemented in service provider networks. IP communications is evolving whether you want to get on the train or not. = I applaud Henning's efforts to push the ball forward. Moving more to an internet model for routing is inevitable, IMHO. There is= questions about how relevant TN is or will be in the near future. For the= sake of having any chance of success, let's simplify the effort and focus = on the future. There will be a transition process to get there, no doubt, = but let's focus on the end goal, and not focus on fixing problems of the pa= st. We are already in a world of multiple private peering arrangements, LC= R, and managing multiple egress points anyway, so the transition should not= be that difficult. I believe a common routing mechanism for both user@domain and TN/e164 based= identities should be the focus. Treat both as first class citizens for IP= communications. Use DNS and domain based routing for all. Use DNSEC to validate and crypto= graphically associate TN/caller-id with a domain (for good guys) and do dom= ain routing from there. =20 Forget about trying to protect TN's individually, that is too complex. It's up to the consumer service providers to enforce and block bad things f= rom bad domains. It's up to wholesale/trunking providers to allow customers to assert their = own domain, or be responsible for asserting domains on their behalf at the = risk of being considered a "bad guy". This is high level, and perhaps a sunny day view of the world, but I don't = think unrealistic. Frankly, if there is any chance of a common federated c= ommunications system continuing to be relevant, I believe a simple approach= that matches the internet model is the only choice. You should see more concrete opinions from Comcast in the future, but I wan= ted to take the opportunity to express these thoughts and would love feedba= ck on why this should or should not be the model going forward. If there is agreement, I believe some of this should be addressed in the ch= arter, because I think some of the assumptions may not enable this path.=20 -Chris On Jun 13, 2013, at 8:51 AM, Dan York wrote: > Hadriel, >=20 > On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >=20 >> That begs the question of what issues you think made Public ENUM fail, >> and why we won't hit the same issues in whatever model we choose. >=20 > Since you addressed this question to me, I feel compelled to answer... bu= t > in the meantime both Brian and Jon have given much more detailed answers > with which I mostly agree. >=20 > I saw security/privacy issues as the main issues that made Public ENUM no= t > work, i.e. Brian's points 4, 5 and 6: >=20 >> 4. Any public database that was able to show any information about a >> telephone number was considered a privacy issue, requiring a lot of "sig= n >> off", which never happened. >> 5. Everyone objected to being able to determine what numbers were "live" >> 6. Carriers objected to a public database that told competitors what >> numbers they controlled >=20 >=20 > The potential for spam was also high. Five or six years ago there was at > least one tool circulating around that would walk an ENUM tree, generate = a > list of all potential phone numbers and then send SIP INVITEs to all of > those numbers. I remember either seeing a video or reading about how > someone did this with all the public ENUM numbers published for Germany > (at that time). So using Public ENUM could be a fantastic way to > potentially get yourself on the calling lists for telemarketers. >=20 > Ideally, I think a public service *would* be a useful way to enable > ubiquitous usage. I'm just not sure how to get there without also opening > a solution up to these same kind of security/privacy issues. >=20 > Dan >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Thu Jun 13 07:08: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 97E9A21F9AEC for ; Thu, 13 Jun 2013 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.391 X-Spam-Level: X-Spam-Status: No, score=-100.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 c+MB7+PmAxvz for ; Thu, 13 Jun 2013 07:08:19 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1D821F9AE7 for ; Thu, 13 Jun 2013 07:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=bjh48NNXvHqSLxALmnVcQsSyFkVbM0DzzCahrXDGyes=; b=kV+o6ZW/23g+nJCx1GA6WShil7dkAZ277Y70+4FjvKveZp3kpM75xR3BThtvjRkNYbXs6XSOHAASdOa5aaDine6xcyNhoEO61SELkK0ytpfhlE0wFv9SSq2nQcDiCx1s6LiuEL+v5BGfGGiJIzq1Mxs3gT4n0aoxcoBVzfOTEhI=; Received: from neustargw.va.neustar.com ([209.173.53.233]:37276 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Un8CH-0007ha-2i; Thu, 13 Jun 2013 10:08:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> Date: Thu, 13 Jun 2013 10:08:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> To: "Wendt, Chris" X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: Dan York , "Peterson, Jon" , Hadriel Kaplan , "stir@ietf.org" , Dave Crocker , Henning Schulzrinne , Stephen Farrell Subject: Re: [stir] current draft 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, 13 Jun 2013 14:08:23 -0000 The IETF is starting a new effort on routing, see the TERQ work. If = you have ideas on routing, that would be the place to bring them. I think the problem we have here is trying to decide who is a "good = guy". Most of the service providers who would would call "pink" in this = context would claim they are good guys. Trying to create a mechanism to = separate good guys from bad guys is very hard. I'm not sure why protecting TNs individually is more complex then the = view you have of routing, especially because we have tried what you are = suggesting, although we did not have DNSSEC. Dealing with the privacy = issues, just to start, would be the first real barrier. Let's say we got beyond that. We then need someone, probably someone = like Neustar, to maintain a per country portion of the database. How = would it do that? Basically, every time a number was delegated, it would change the domain = of the entry to reflect the delegation. That could work. What it means = is that delegation of any kind has to be recorded in the new database. = If you note, certs follow delegation, with you inserting "domain" in the = middle (domain follows delegation). The twist is that instead of a 2nd = level reseller issuing a cert to a 3rd level reseller, the 2nd level = reseller goes to the new database and has them effectively do the same = thing. =20 Having databases that associate a domain with a TN might help things = like finding a cert, but it doesn't affect the basic issue of how you = avoid spoofing. Do you think the approach we have suggested here = (signing of From/To/Time/Session Id) with a cert traceable to the = identity is appropriate? If you are "simply" suggesting the cert is located via DANE in the = domain of the caller, then for user@domain, I think we're probably = saying the same thing. Where we seem to differ is that you suggest we = have a DNS entry for the TN that has the domain in it, and then you use = that to find the cert used for signing. In the basic case, we're = suggesting a URI to the cert in the signaling, which seems simpler. = What matters however is how the DNS tree for the TNs is maintained. So, my response is the same as I have given before: the privacy and = operational issues of putting per TN information in the public DNS are = overwhelming. We have tried it, and it has failed. =20 Unlike Hadriel, you really do want to disclose domain with TN. That has = been a non-starter for many carriers. Brian On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" = wrote: > Hi Folks, >=20 > I believe it couldn't be a better time to start discussing public = routing. While this is a little beyond the scope of protecting = caller-id, I think the effort is highly complimentary, and solving both = together will provide a better path to get things implemented in service = provider networks. >=20 > IP communications is evolving whether you want to get on the train or = not. I applaud Henning's efforts to push the ball forward. >=20 > Moving more to an internet model for routing is inevitable, IMHO. = There is questions about how relevant TN is or will be in the near = future. For the sake of having any chance of success, let's simplify = the effort and focus on the future. There will be a transition process = to get there, no doubt, but let's focus on the end goal, and not focus = on fixing problems of the past. We are already in a world of multiple = private peering arrangements, LCR, and managing multiple egress points = anyway, so the transition should not be that difficult. >=20 > I believe a common routing mechanism for both user@domain and TN/e164 = based identities should be the focus. Treat both as first class = citizens for IP communications. >=20 > Use DNS and domain based routing for all. Use DNSEC to validate and = cryptographically associate TN/caller-id with a domain (for good guys) = and do domain routing from there. =20 > Forget about trying to protect TN's individually, that is too complex. >=20 > It's up to the consumer service providers to enforce and block bad = things from bad domains. > It's up to wholesale/trunking providers to allow customers to assert = their own domain, or be responsible for asserting domains on their = behalf at the risk of being considered a "bad guy". >=20 > This is high level, and perhaps a sunny day view of the world, but I = don't think unrealistic. Frankly, if there is any chance of a common = federated communications system continuing to be relevant, I believe a = simple approach that matches the internet model is the only choice. >=20 > You should see more concrete opinions from Comcast in the future, but = I wanted to take the opportunity to express these thoughts and would = love feedback on why this should or should not be the model going = forward. >=20 > If there is agreement, I believe some of this should be addressed in = the charter, because I think some of the assumptions may not enable this = path.=20 >=20 > -Chris >=20 >=20 >=20 >=20 > On Jun 13, 2013, at 8:51 AM, Dan York wrote: >=20 >> Hadriel, >>=20 >> On 6/12/13 5:38 PM, "Hadriel Kaplan" = wrote: >>=20 >>> That begs the question of what issues you think made Public ENUM = fail, >>> and why we won't hit the same issues in whatever model we choose. >>=20 >> Since you addressed this question to me, I feel compelled to = answer... but >> in the meantime both Brian and Jon have given much more detailed = answers >> with which I mostly agree. >>=20 >> I saw security/privacy issues as the main issues that made Public = ENUM not >> work, i.e. Brian's points 4, 5 and 6: >>=20 >>> 4. Any public database that was able to show any information about a >>> telephone number was considered a privacy issue, requiring a lot of = "sign >>> off", which never happened. >>> 5. Everyone objected to being able to determine what numbers were = "live" >>> 6. Carriers objected to a public database that told competitors what >>> numbers they controlled >>=20 >>=20 >> The potential for spam was also high. Five or six years ago there = was at >> least one tool circulating around that would walk an ENUM tree, = generate a >> list of all potential phone numbers and then send SIP INVITEs to all = of >> those numbers. I remember either seeing a video or reading about how >> someone did this with all the public ENUM numbers published for = Germany >> (at that time). So using Public ENUM could be a fantastic way to >> potentially get yourself on the calling lists for telemarketers. >>=20 >> Ideally, I think a public service *would* be a useful way to enable >> ubiquitous usage. I'm just not sure how to get there without also = opening >> a solution up to these same kind of security/privacy issues. >>=20 >> Dan >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=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 richard@shockey.us Thu Jun 13 09:07: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 5BCAE21F9A1F for ; Thu, 13 Jun 2013 09:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=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 LqRmqwbyf6Rm for ; Thu, 13 Jun 2013 09:07:35 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 78CE321F9A03 for ; Thu, 13 Jun 2013 09:07:32 -0700 (PDT) Received: (qmail 8120 invoked by uid 0); 13 Jun 2013 14:42:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 13 Jun 2013 14:42:05 -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=1CLEWUsNE4bsCrwS8IIwJNEVOIESjn8ZVpGyxSx3Wzc=; b=a7vpsIzcQ1N6GGL71R8UpB4pWzqJofE0deVCEHckgqzPCQoOLTtEsZJKWQNjMlK8Hml1RBNkko8jf8qq1w5SWqDyMS1KIQuu66UClcGxVKsA8t/l0J7om3YfBU+ur+Mn; Received: from [72.66.111.124] (port=50970 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Un8iz-0005IY-Jy; Thu, 13 Jun 2013 08:42:05 -0600 From: "Richard Shockey" To: "'Peterson, Jon'" , "'PFAUTZ, PENN L'" , "'Hadriel Kaplan'" , "'Brian Rosen'" References: <38726EDA2109264987B45E29E758C4D604857FED@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: Date: Thu, 13 Jun 2013 10:42:02 -0400 Message-ID: <028b01ce6844$2b86c340$829449c0$@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: AQKeUtNKlLoGjpillw2645qKXVDw55eT4oFA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Henning Schulzrinne' Subject: Re: [stir] DKIM-like key mgmt approach X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 13 Jun 2013 16:07:40 -0000 +1 .. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, June 12, 2013 6:17 PM To: PFAUTZ, PENN L; Hadriel Kaplan; Brian Rosen Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] DKIM-like key mgmt approach Agreed that it is better to work from the nation level up than to try to trickle this down from a global root. There are technologies (like LoST, used in ECRIT) that are designed to have allow a more opt-in structure for navigating between trees like this. Perhaps we could look into technology like that to help us figure out the right way to work this. Jon Peterson Neustar, Inc. On 6/12/13 5:32 AM, "PFAUTZ, PENN L" wrote: >I think Hadriel is on the right track. As to the globalization issue, >my takeaway from efforts to build an authoritative global enum tree is >that you will need to work from national authorities up. If you get per >country data sources it will not be hard to link them together/interwork. >This approach also provides some national flexibility. > >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 >Hadriel Kaplan >Sent: Tuesday, June 11, 2013 5:35 PM >To: Brian Rosen >Cc: stir@ietf.org; Henning Schulzrinne >Subject: Re: [stir] DKIM-like key mgmt approach > > >On Jun 11, 2013, at 4:00 PM, Brian Rosen wrote: > >> If you put in in public enum, you have all of the problems of >>managing the tree that eluded us. As a practical matter, you get >>carriers to pay a third party database company to manage the +1 tree, a la cc1enum. > >Not necessarily. For each country code, you make their numbering plan >admin the authority. For example for +1, you make NANPA the authority >(or maybe NANC or whatever it needs to be). They're "responsible" for >generating a unique key pair for each +1 E.164 signed by their root >cert, giving the key pair to the org they give the number to, and >hosting the pub key for each in a DNS structure. > >Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN >doesn't do the work for DNS. NANPA contracts with someone else to do >it, like Neustar (which as far as I know runs NANPA). Since they're >doing it all in bulk, then the per number entry it shouldn't cost >anywhere near what normal domain name registrations do. NANPA gets the >money for it from the E.164 number allocation fee, annual maintenance >fee, and change fee or whatever. > >I'm not saying getting this done is easy - it's NOT - but nothing we do >is going to be. At least this way there's only one organization to >deal with to get the cert-db part done, per country. > > >> In the U.S., it could be NPAC that held the per-TN data. It already >>does for most numbers. Having NPAC provide an ENUM query in e164.arpa >>is certainly possible, but I think would be an enormous effort to get >>approved. Having it supply a query to SPs based on a sane query >>protocol like a web service would be better and much easier to get >>fielded. Way too much baggage in ENUM I think. > >But the NPAC only holds data for NANP-based numbers. How does a US >carrier authenticate a number from the UK or Germany or wherever? > >-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 hadriel.kaplan@oracle.com Thu Jun 13 09: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 80B8021F9A1C for ; Thu, 13 Jun 2013 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 nxv9k74+6-uT for ; Thu, 13 Jun 2013 09:14:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D921F994F for ; Thu, 13 Jun 2013 09:14:13 -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 r5DGDrmY003214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 16:13:54 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 r5DGDrQ4001388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 16:13:54 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5DGDrVo016576; Thu, 13 Jun 2013 16:13:53 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Jun 2013 09:13:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 13 Jun 2013 12:13:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <59D0F1E7-7682-4787-B93F-D17C64D27B23@oracle.com> References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Wendt, Chris" , Dan York , "Peterson, Jon" , "stir@ietf.org" , Dave Crocker , Stephen Farrell , Henning Schulzrinne Subject: Re: [stir] current draft 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, 13 Jun 2013 16:14:24 -0000 On Jun 13, 2013, at 10:08 AM, Brian Rosen wrote: > So, my response is the same as I have given before: the privacy and = operational issues of putting per TN information in the public DNS are = overwhelming. We have tried it, and it has failed. The privacy issues can be avoided. The operational issues, however, are quite significant. But I don't see = how they're not significant no matter what databases we put them in. No = matter whether it's a private database or public one: there will be new = operational procedures, forms to fill out, help desk people to handle = problems with it, configuration and deployment of stuff, NOC personnel = to train, testing to do, monitoring systems to monitor it, etc., etc. In short: it's a very big deal. Luckily history has shown that some third-party service companies will = make themselves available to do most of the work for carriers that don't = want to do it themselves, for a fee. It might be the number portability = vendors, or CNAM vendors, or something new. Either way, they can handle = most of the heavy lifting for carriers who don't want to. If we choose = a DNS model, then those third-party vendors would then interface to the = DNS admin; or maybe they start with a private federation of servers just = among the third-party companies. The reason Public ENUM failed wasn't because it was an operational = nightmare - if Public ENUM had some actual useful benefit to the = stakeholders, then all other issues would have gone away or been dealt = with. I.e., if the carriers *want* something, then they figure out how = to get it done, how to lobby their Regulators, and how to get the ITU to = go along. If they don't want it, then every possible issue that can be = raised becomes "impossible to fix". And I'm not saying that's wrong = either. (and everyone does the same thing in the IETF, regularly) > Unlike Hadriel, you really do want to disclose domain with TN. That = has been a non-starter for many carriers. In my defense, it's not that *I* don't want to disclose the domain of = the TN - I'd be perfectly happy with it - it's that I'm pretty sure a = lot of providers AND Enterprises would not, if it means you can discover = all the TNs belonging to the domain. And you don't need to go very far = to find evidence of that: how many companies want to publicly disclose = all their users' email addresses? Of my current and half-dozen previous = employers, none would want them exposed. -hadriel From chris_wendt@cable.comcast.com Thu Jun 13 09:19: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 5C62B21F9A52 for ; Thu, 13 Jun 2013 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 mn8OpXZjcfh1 for ; Thu, 13 Jun 2013 09:18:52 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51C21F9A24 for ; Thu, 13 Jun 2013 09:18:52 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.77106757; Thu, 13 Jun 2013 10:18:05 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.49]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 13 Jun 2013 12:18:04 -0400 From: "Wendt, Chris" To: Brian Rosen Thread-Topic: [stir] current draft charter Thread-Index: AQHOaDsmzzxiRhKUq0SNP5wemGrczQ== Date: Thu, 13 Jun 2013 16:18:03 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD94122025B@PACDCEXMB01.cable.comcast.com> References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dan York , "Peterson, Jon" , Hadriel Kaplan , "stir@ietf.org" , Dave Crocker , Henning Schulzrinne , Stephen Farrell Subject: Re: [stir] current draft 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, 13 Jun 2013 16:19:08 -0000 Thanks Brian.=20 Answer inline. On Jun 13, 2013, at 10:08 AM, Brian Rosen wrote: > The IETF is starting a new effort on routing, see the TERQ work. If you= have ideas on routing, that would be the place to bring them. >=20 > I think the problem we have here is trying to decide who is a "good guy".= Most of the service providers who would would call "pink" in this context= would claim they are good guys. Trying to create a mechanism to separate = good guys from bad guys is very hard. >=20 Sure, they assert their domain, provide DNSSEC to verify, but we notice cus= tomer complaints and shut them down. Plus have cryptographic evidence that= it was indeed coming from them. I think that works pretty well. =20 If a "bad guy" chooses not to participate in asserting domain, then the ser= vice provider can choose whether to accept the calls. > I'm not sure why protecting TNs individually is more complex then the vie= w you have of routing, especially because we have tried what you are sugges= ting, although we did not have DNSSEC. Dealing with the privacy issues, ju= st to start, would be the first real barrier. I probably don't fully understand the privacy issue, but to me the only thi= ng potentially exposed is the domain that owns the telephone number. >=20 > Let's say we got beyond that. We then need someone, probably someone lik= e Neustar, to maintain a per country portion of the database. How would it= do that? >=20 > Basically, every time a number was delegated, it would change the domain = of the entry to reflect the delegation. That could work. What it means is= that delegation of any kind has to be recorded in the new database. If yo= u note, certs follow delegation, with you inserting "domain" in the middle = (domain follows delegation). The twist is that instead of a 2nd level rese= ller issuing a cert to a 3rd level reseller, the 2nd level reseller goes to= the new database and has them effectively do the same thing. =20 So, I defer here to better experts than myself. >=20 > Having databases that associate a domain with a TN might help things like= finding a cert, but it doesn't affect the basic issue of how you avoid spo= ofing. Do you think the approach we have suggested here (signing of From/T= o/Time/Session Id) with a cert traceable to the identity is appropriate? I just think it's overboard to have a cert per identity and I don't believe= a service provider I want to police calls TN by TN. =20 It's the domain representing the wholesale provider or PBX or whatever that= we want to police, I think. >=20 > If you are "simply" suggesting the cert is located via DANE in the domain= of the caller, then for user@domain, I think we're probably saying the sam= e thing. Where we seem to differ is that you suggest we have a DNS entry f= or the TN that has the domain in it, and then you use that to find the cert= used for signing. In the basic case, we're suggesting a URI to the cert i= n the signaling, which seems simpler. What matters however is how the DNS = tree for the TNs is maintained. I think using standard DNSSEC mechanisms is simpler and more straight forwa= rd, but that's an opinion guided by domain routing as the end state. Although, I think perhaps it might be wise to have a guiding philosophy tha= t I hope most would agree with. If we are creating new mechanisms to do th= ings, we are doing it wrong. >=20 > So, my response is the same as I have given before: the privacy and opera= tional issues of putting per TN information in the public DNS are overwhelm= ing. We have tried it, and it has failed. =20 I think the main issue, to your point above, is management of a TLD, but i = think it's solvable, we have lots of smart people. =20 If the privacy issue is really an issue, then lets discuss further. This will be a transition from private databases to a fully distributed sys= tem, and I think the long term issue will be the desire to move to this mod= el or a push from regulatory entities if that is where we/they want to go. = In some sense, I think there will be a lot of benefit to it and allow for = much better communications applications in the future, but this is speculat= ion. In the end, we have a great distributed internet model for transporting dat= a, securing data, cryptographic verification of destination and origination= , why shouldn't we push that direction for communications as well, isn't th= at the point? Or better yet, why won't it be the end state anyway whether = the traditional players are involved or not. Failure is not an option :) >=20 > Unlike Hadriel, you really do want to disclose domain with TN. That has = been a non-starter for many carriers. >=20 > Brian >=20 >=20 > On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" wrote: >=20 >> Hi Folks, >>=20 >> I believe it couldn't be a better time to start discussing public routin= g. While this is a little beyond the scope of protecting caller-id, I thin= k the effort is highly complimentary, and solving both together will provid= e a better path to get things implemented in service provider networks. >>=20 >> IP communications is evolving whether you want to get on the train or no= t. I applaud Henning's efforts to push the ball forward. >>=20 >> Moving more to an internet model for routing is inevitable, IMHO. There= is questions about how relevant TN is or will be in the near future. For = the sake of having any chance of success, let's simplify the effort and foc= us on the future. There will be a transition process to get there, no doub= t, but let's focus on the end goal, and not focus on fixing problems of the= past. We are already in a world of multiple private peering arrangements,= LCR, and managing multiple egress points anyway, so the transition should = not be that difficult. >>=20 >> I believe a common routing mechanism for both user@domain and TN/e164 ba= sed identities should be the focus. Treat both as first class citizens for= IP communications. >>=20 >> Use DNS and domain based routing for all. Use DNSEC to validate and cry= ptographically associate TN/caller-id with a domain (for good guys) and do = domain routing from there. =20 >> Forget about trying to protect TN's individually, that is too complex. >>=20 >> It's up to the consumer service providers to enforce and block bad thing= s from bad domains. >> It's up to wholesale/trunking providers to allow customers to assert the= ir own domain, or be responsible for asserting domains on their behalf at t= he risk of being considered a "bad guy". >>=20 >> This is high level, and perhaps a sunny day view of the world, but I don= 't think unrealistic. Frankly, if there is any chance of a common federate= d communications system continuing to be relevant, I believe a simple appro= ach that matches the internet model is the only choice. >>=20 >> You should see more concrete opinions from Comcast in the future, but I = wanted to take the opportunity to express these thoughts and would love fee= dback on why this should or should not be the model going forward. >>=20 >> If there is agreement, I believe some of this should be addressed in the= charter, because I think some of the assumptions may not enable this path.= =20 >>=20 >> -Chris >>=20 >>=20 >>=20 >>=20 >> On Jun 13, 2013, at 8:51 AM, Dan York wrote: >>=20 >>> Hadriel, >>>=20 >>> On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >>>=20 >>>> That begs the question of what issues you think made Public ENUM fail, >>>> and why we won't hit the same issues in whatever model we choose. >>>=20 >>> Since you addressed this question to me, I feel compelled to answer... = but >>> in the meantime both Brian and Jon have given much more detailed answer= s >>> with which I mostly agree. >>>=20 >>> I saw security/privacy issues as the main issues that made Public ENUM = not >>> work, i.e. Brian's points 4, 5 and 6: >>>=20 >>>> 4. Any public database that was able to show any information about a >>>> telephone number was considered a privacy issue, requiring a lot of "s= ign >>>> off", which never happened. >>>> 5. Everyone objected to being able to determine what numbers were "liv= e" >>>> 6. Carriers objected to a public database that told competitors what >>>> numbers they controlled >>>=20 >>>=20 >>> The potential for spam was also high. Five or six years ago there was = at >>> least one tool circulating around that would walk an ENUM tree, generat= e a >>> list of all potential phone numbers and then send SIP INVITEs to all of >>> those numbers. I remember either seeing a video or reading about how >>> someone did this with all the public ENUM numbers published for Germany >>> (at that time). So using Public ENUM could be a fantastic way to >>> potentially get yourself on the calling lists for telemarketers. >>>=20 >>> Ideally, I think a public service *would* be a useful way to enable >>> ubiquitous usage. I'm just not sure how to get there without also openi= ng >>> a solution up to these same kind of security/privacy issues. >>>=20 >>> Dan >>>=20 >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org +1-802-735-1624 >>> Jabber: york@jabber.isoc.org >>> Skype: danyork http://twitter.com/danyork >>>=20 >>> http://www.internetsociety.org/deploy360/ >>>=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 richard@shockey.us Thu Jun 13 09:43: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 F04EE21F9A84 for ; Thu, 13 Jun 2013 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.091 X-Spam-Level: X-Spam-Status: No, score=-101.091 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 1kZvkyiDeP6z for ; Thu, 13 Jun 2013 09:43:47 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (unknown [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 3B1C421F9A1A for ; Thu, 13 Jun 2013 09:43:47 -0700 (PDT) Received: (qmail 26511 invoked by uid 0); 13 Jun 2013 16:39:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 13 Jun 2013 16:39:17 -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=o/g4pZglpcfHuKflbeL5nZq552w9l+P9DkcJUH0vdno=; b=SerLpoU3qz+ITzzm39SZq5i5o14N2w5tPBlFeqGT3IMZIQlZjiIr7nNAhNxEBTlIhnKre+VvLQ/dy/Z2ISJP63SGpX+u8T1+wLQvmSKO9s5P+FZLbV5VrJmKMq7anxQy; Received: from [72.66.111.124] (port=51539 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UnAYP-0000vD-8g; Thu, 13 Jun 2013 10:39:17 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Wendt, Chris'" References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> In-Reply-To: Date: Thu, 13 Jun 2013 12:39:13 -0400 Message-ID: <02cf01ce6854$8ab396d0$a01ac470$@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: AQHurB+rPvBwdWSMpuU+7zbFbFufQwKXAQNEAepiKvKYz0IJUA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: 'Dan York' , "'Peterson, Jon'" , 'Hadriel Kaplan' , stir@ietf.org, 'Dave Crocker' , 'Stephen Farrell' , 'Henning Schulzrinne' Subject: Re: [stir] current draft 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, 13 Jun 2013 16:43:53 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, June 13, 2013 10:08 AM To: Wendt, Chris Cc: Dan York; Peterson, Jon; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Henning Schulzrinne; Stephen Farrell Subject: Re: [stir] current draft charter The IETF is starting a new effort on routing, see the TERQ work. If you have ideas on routing, that would be the place to bring them. [RS> ] [RS> ] Wait a second.. You are demonstrating a profound misunderstanding of what a service provider has in place or are capable of actually implementing within a reasonable time frame. It is not utterly unreasonable to at least consider that the issues of number resolution for TN Source Authentication or Routing would be somewhat similar. There is infrastructure and technology in place. Dismissing that question out of hand is absurd. Frankly the way the IETF works these days the chances of TERQ actually deploying before the End of Ages is debatable. You know the timelines as well as anyone ... 4 years for a RFC then 2 years for it to show up on carrier requirements, regression testing .. vendor selection. Get a grip. I think the problem we have here is trying to decide who is a "good guy". Most of the service providers who would would call "pink" in this context would claim they are good guys. Trying to create a mechanism to separate good guys from bad guys is very hard. I'm not sure why protecting TNs individually is more complex then the view you have of routing, especially because we have tried what you are suggesting, although we did not have DNSSEC. Dealing with the privacy issues, just to start, would be the first real barrier. Let's say we got beyond that. We then need someone, probably someone like Neustar, to maintain a per country portion of the database. How would it do that? [RS> ] OH PLEASE.. I love a good global domination strategy as much as the next red blooded capitalist but these endless references to ..."somelike NeuStar" are becoming tedious and inappropriate. Basically, every time a number was delegated, it would change the domain of the entry to reflect the delegation. That could work. What it means is that delegation of any kind has to be recorded in the new database. If you note, certs follow delegation, with you inserting "domain" in the middle (domain follows delegation). The twist is that instead of a 2nd level reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes to the new database and has them effectively do the same thing. Having databases that associate a domain with a TN might help things like finding a cert, but it doesn't affect the basic issue of how you avoid spoofing. Do you think the approach we have suggested here (signing of From/To/Time/Session Id) with a cert traceable to the identity is appropriate? If you are "simply" suggesting the cert is located via DANE in the domain of the caller, then for user@domain, I think we're probably saying the same thing. Where we seem to differ is that you suggest we have a DNS entry for the TN that has the domain in it, and then you use that to find the cert used for signing. In the basic case, we're suggesting a URI to the cert in the signaling, which seems simpler. What matters however is how the DNS tree for the TNs is maintained. So, my response is the same as I have given before: the privacy and operational issues of putting per TN information in the public DNS are overwhelming. We have tried it, and it has failed. Unlike Hadriel, you really do want to disclose domain with TN. That has been a non-starter for many carriers. Brian On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" wrote: > Hi Folks, > > I believe it couldn't be a better time to start discussing public routing. While this is a little beyond the scope of protecting caller-id, I think the effort is highly complimentary, and solving both together will provide a better path to get things implemented in service provider networks. > > IP communications is evolving whether you want to get on the train or not. I applaud Henning's efforts to push the ball forward. > > Moving more to an internet model for routing is inevitable, IMHO. There is questions about how relevant TN is or will be in the near future. For the sake of having any chance of success, let's simplify the effort and focus on the future. There will be a transition process to get there, no doubt, but let's focus on the end goal, and not focus on fixing problems of the past. We are already in a world of multiple private peering arrangements, LCR, and managing multiple egress points anyway, so the transition should not be that difficult. > > I believe a common routing mechanism for both user@domain and TN/e164 based identities should be the focus. Treat both as first class citizens for IP communications. > > Use DNS and domain based routing for all. Use DNSEC to validate and cryptographically associate TN/caller-id with a domain (for good guys) and do domain routing from there. > Forget about trying to protect TN's individually, that is too complex. > > It's up to the consumer service providers to enforce and block bad things from bad domains. > It's up to wholesale/trunking providers to allow customers to assert their own domain, or be responsible for asserting domains on their behalf at the risk of being considered a "bad guy". > > This is high level, and perhaps a sunny day view of the world, but I don't think unrealistic. Frankly, if there is any chance of a common federated communications system continuing to be relevant, I believe a simple approach that matches the internet model is the only choice. > > You should see more concrete opinions from Comcast in the future, but I wanted to take the opportunity to express these thoughts and would love feedback on why this should or should not be the model going forward. > > If there is agreement, I believe some of this should be addressed in the charter, because I think some of the assumptions may not enable this path. > > -Chris > > > > > On Jun 13, 2013, at 8:51 AM, Dan York wrote: > >> Hadriel, >> >> On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >> >>> That begs the question of what issues you think made Public ENUM >>> fail, and why we won't hit the same issues in whatever model we choose. >> >> Since you addressed this question to me, I feel compelled to >> answer... but in the meantime both Brian and Jon have given much more >> detailed answers with which I mostly agree. >> >> I saw security/privacy issues as the main issues that made Public >> ENUM not work, i.e. Brian's points 4, 5 and 6: >> >>> 4. Any public database that was able to show any information about a >>> telephone number was considered a privacy issue, requiring a lot of >>> "sign off", which never happened. >>> 5. Everyone objected to being able to determine what numbers were "live" >>> 6. Carriers objected to a public database that told competitors what >>> numbers they controlled >> >> >> The potential for spam was also high. Five or six years ago there >> was at least one tool circulating around that would walk an ENUM >> tree, generate a list of all potential phone numbers and then send >> SIP INVITEs to all of those numbers. I remember either seeing a >> video or reading about how someone did this with all the public ENUM >> numbers published for Germany (at that time). So using Public ENUM >> could be a fantastic way to potentially get yourself on the calling lists for telemarketers. >> >> Ideally, I think a public service *would* be a useful way to enable >> ubiquitous usage. I'm just not sure how to get there without also >> opening a solution up to these same kind of security/privacy issues. >> >> Dan >> >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >> >> http://www.internetsociety.org/deploy360/ >> >> _______________________________________________ >> 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 Thu Jun 13 09:52: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 3DA3521F99C1 for ; Thu, 13 Jun 2013 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.395 X-Spam-Level: X-Spam-Status: No, score=-100.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 sgg9ZPeIfID1 for ; Thu, 13 Jun 2013 09:52:16 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0421821F963C for ; Thu, 13 Jun 2013 09:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mN+uKXwGSg8As/pKvpnAn12zg+s6NbFzAesqMDN7cfo=; b=isL8C4t5ehdLPoQoT9OhUuXZP7AZfHsR9C/5BOdMx/FC2fv1su9ucEJuNQyw/AQraeHo/xey2gi25V4HRRBmEjE8WRXCt0+/j+YhBbuPzkm/kYOFAPVNPpO3zfNdOqLHzAY3QHy9jc1A/cNKrmdgLPxnfU1V3PQTeFNN9k+xZ1o=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42693 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UnAkW-0003R6-Ms; Thu, 13 Jun 2013 12:51:49 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> Date: Thu, 13 Jun 2013 12:51:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net> References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "'Wendt, Chris'" , 'Dan York' , "'Peterson, Jon'" , 'Hadriel Kaplan' , stir@ietf.org, 'Dave Crocker' , 'Stephen Farrell' , 'Henning Schulzrinne' Subject: Re: [stir] current draft 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, 13 Jun 2013 16:52:25 -0000 This particular effort is aimed at trying to do something about = robocalling, vishing and swatting in a relatively short time frame. To = many of us, that seems doable. Re-doing how routing of telephone number based identities work is the = charter of TERQ. It probably can't be done relatively quickly, no = matter what mechanisms are used. Restricting charter is a time-honored way of getting stuff done. I'll = take that path without any qualms. I'm not interested in re-doing = routing of telephone number identities as part of this work. The point of asserting that it takes someone like Neustar to handle a = database like what is being described is that a DNS based tree doesn't = map into the way number delegation works - so the entire tree has to be = handled by one entity - you can't delegate part of it to someone else, = especially when porting is considered. I was trying to contrast that = with the model I've described where cert delegation follows number = delegation. That doesn't require a monolithic database. Brian On Jun 13, 2013, at 12:39 PM, Richard Shockey = wrote: >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Thursday, June 13, 2013 10:08 AM > To: Wendt, Chris > Cc: Dan York; Peterson, Jon; Hadriel Kaplan; stir@ietf.org; Dave = Crocker; > Henning Schulzrinne; Stephen Farrell > Subject: Re: [stir] current draft charter >=20 > The IETF is starting a new effort on routing, see the TERQ work. If = you > have ideas on routing, that would be the place to bring them. > [RS> ]=20 > [RS> ] Wait a second.. You are demonstrating a profound = misunderstanding of > what a service provider has in place or are capable of actually = implementing > within a reasonable time frame. It is not utterly unreasonable to at = least > consider that the issues of number resolution for TN Source = Authentication > or Routing would be somewhat similar. There is infrastructure and > technology in place. Dismissing that question out of hand is absurd. > Frankly the way the IETF works these days the chances of TERQ actually > deploying before the End of Ages is debatable. You know the timelines = as > well as anyone ... 4 years for a RFC then 2 years for it to show up on > carrier requirements, regression testing .. vendor selection. Get a = grip.=20 >=20 >=20 > I think the problem we have here is trying to decide who is a "good = guy". > Most of the service providers who would would call "pink" in this = context > would claim they are good guys. Trying to create a mechanism to = separate > good guys from bad guys is very hard. >=20 > I'm not sure why protecting TNs individually is more complex then the = view > you have of routing, especially because we have tried what you are > suggesting, although we did not have DNSSEC. Dealing with the privacy > issues, just to start, would be the first real barrier. >=20 > Let's say we got beyond that. We then need someone, probably someone = like > Neustar, to maintain a per country portion of the database. How would = it do > that? >=20 > [RS> ] OH PLEASE.. I love a good global domination strategy as much = as the > next red blooded capitalist but these endless references to = ..."somelike > NeuStar" are becoming tedious and inappropriate.=20 >=20 >=20 > Basically, every time a number was delegated, it would change the = domain of > the entry to reflect the delegation. That could work. What it means = is > that delegation of any kind has to be recorded in the new database. = If you > note, certs follow delegation, with you inserting "domain" in the = middle > (domain follows delegation). The twist is that instead of a 2nd level > reseller issuing a cert to a 3rd level reseller, the 2nd level = reseller goes > to the new database and has them effectively do the same thing. =20 >=20 > Having databases that associate a domain with a TN might help things = like > finding a cert, but it doesn't affect the basic issue of how you avoid > spoofing. Do you think the approach we have suggested here (signing = of > From/To/Time/Session Id) with a cert traceable to the identity is > appropriate? >=20 > If you are "simply" suggesting the cert is located via DANE in the = domain of > the caller, then for user@domain, I think we're probably saying the = same > thing. Where we seem to differ is that you suggest we have a DNS = entry for > the TN that has the domain in it, and then you use that to find the = cert > used for signing. In the basic case, we're suggesting a URI to the = cert in > the signaling, which seems simpler. What matters however is how the = DNS > tree for the TNs is maintained. >=20 > So, my response is the same as I have given before: the privacy and > operational issues of putting per TN information in the public DNS are > overwhelming. We have tried it, and it has failed. =20 >=20 > Unlike Hadriel, you really do want to disclose domain with TN. That = has > been a non-starter for many carriers. >=20 > Brian >=20 >=20 > On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" = > wrote: >=20 >> Hi Folks, >>=20 >> I believe it couldn't be a better time to start discussing public = routing. > While this is a little beyond the scope of protecting caller-id, I = think the > effort is highly complimentary, and solving both together will provide = a > better path to get things implemented in service provider networks. >>=20 >> IP communications is evolving whether you want to get on the train or = not. > I applaud Henning's efforts to push the ball forward. >>=20 >> Moving more to an internet model for routing is inevitable, IMHO. = There > is questions about how relevant TN is or will be in the near future. = For > the sake of having any chance of success, let's simplify the effort = and > focus on the future. There will be a transition process to get there, = no > doubt, but let's focus on the end goal, and not focus on fixing = problems of > the past. We are already in a world of multiple private peering > arrangements, LCR, and managing multiple egress points anyway, so the > transition should not be that difficult. >>=20 >> I believe a common routing mechanism for both user@domain and TN/e164 > based identities should be the focus. Treat both as first class = citizens > for IP communications. >>=20 >> Use DNS and domain based routing for all. Use DNSEC to validate and > cryptographically associate TN/caller-id with a domain (for good guys) = and > do domain routing from there. =20 >> Forget about trying to protect TN's individually, that is too = complex. >>=20 >> It's up to the consumer service providers to enforce and block bad = things > from bad domains. >> It's up to wholesale/trunking providers to allow customers to assert = their > own domain, or be responsible for asserting domains on their behalf at = the > risk of being considered a "bad guy". >>=20 >> This is high level, and perhaps a sunny day view of the world, but I = don't > think unrealistic. Frankly, if there is any chance of a common = federated > communications system continuing to be relevant, I believe a simple = approach > that matches the internet model is the only choice. >>=20 >> You should see more concrete opinions from Comcast in the future, but = I > wanted to take the opportunity to express these thoughts and would = love > feedback on why this should or should not be the model going forward. >>=20 >> If there is agreement, I believe some of this should be addressed in = the > charter, because I think some of the assumptions may not enable this = path.=20 >>=20 >> -Chris >>=20 >>=20 >>=20 >>=20 >> On Jun 13, 2013, at 8:51 AM, Dan York wrote: >>=20 >>> Hadriel, >>>=20 >>> On 6/12/13 5:38 PM, "Hadriel Kaplan" = wrote: >>>=20 >>>> That begs the question of what issues you think made Public ENUM=20 >>>> fail, and why we won't hit the same issues in whatever model we = choose. >>>=20 >>> Since you addressed this question to me, I feel compelled to=20 >>> answer... but in the meantime both Brian and Jon have given much = more=20 >>> detailed answers with which I mostly agree. >>>=20 >>> I saw security/privacy issues as the main issues that made Public=20 >>> ENUM not work, i.e. Brian's points 4, 5 and 6: >>>=20 >>>> 4. Any public database that was able to show any information about = a=20 >>>> telephone number was considered a privacy issue, requiring a lot of=20= >>>> "sign off", which never happened. >>>> 5. Everyone objected to being able to determine what numbers were = "live" >>>> 6. Carriers objected to a public database that told competitors = what=20 >>>> numbers they controlled >>>=20 >>>=20 >>> The potential for spam was also high. Five or six years ago there=20= >>> was at least one tool circulating around that would walk an ENUM=20 >>> tree, generate a list of all potential phone numbers and then send=20= >>> SIP INVITEs to all of those numbers. I remember either seeing a=20 >>> video or reading about how someone did this with all the public ENUM=20= >>> numbers published for Germany (at that time). So using Public ENUM=20= >>> could be a fantastic way to potentially get yourself on the calling = lists > for telemarketers. >>>=20 >>> Ideally, I think a public service *would* be a useful way to enable=20= >>> ubiquitous usage. I'm just not sure how to get there without also=20 >>> opening a solution up to these same kind of security/privacy issues. >>>=20 >>> Dan >>>=20 >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org +1-802-735-1624 >>> Jabber: york@jabber.isoc.org >>> Skype: danyork http://twitter.com/danyork >>>=20 >>> http://www.internetsociety.org/deploy360/ >>>=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 >=20 From richard@shockey.us Thu Jun 13 10:12: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 C9C5E21F9A0C for ; Thu, 13 Jun 2013 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.006 X-Spam-Level: X-Spam-Status: No, score=-101.006 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 1FzClPvIZ8kL for ; Thu, 13 Jun 2013 10:12:33 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (unknown [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 194A921F9A11 for ; Thu, 13 Jun 2013 10:12:32 -0700 (PDT) Received: (qmail 23102 invoked by uid 0); 13 Jun 2013 15:30:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 13 Jun 2013 15:30:55 -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=NahfAEq5AhocO5yaoT6cqQFfVS6ez3QjGzRGxYZlKoE=; b=ncIv/qFiuJwelfcaY2NRfhb9rMinVJKEdsLzkHBShZ3KoX7u1+/ruOU1DytKwqfbZq6fzbivVCAbfYWoVI06ZRw4uBYSDlaKjNC5mkKMkCcFL3XoLErPPKqdAnMvk87i; Received: from [72.66.111.124] (port=51049 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Un9UF-0006FX-06; Thu, 13 Jun 2013 09:30:55 -0600 From: "Richard Shockey" To: "'Dan York'" , "'Hadriel Kaplan'" References: In-Reply-To: Date: Thu, 13 Jun 2013 11:30:48 -0400 Message-ID: <029c01ce684a$fd914df0$f8b3e9d0$@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: AQHurB+rPvBwdWSMpuU+7zbFbFufQ5jzJQcg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Dave Crocker' Subject: Re: [stir] current draft 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, 13 Jun 2013 17:12:38 -0000 Since it seems folks want some authoritative history of 6116 I suppose I should oblige. I only co-chaired the ENUM WG for nearly 8 years. Brother Pfautz can also relate the issues. There were multiple reasons e164.arpa failed though 6116 technology has worked very well imbedded in carrier networks as a TCAP replacement where the CSCF or SIP proxy needs to perform some form of number translation for some data or metadata, typically for the call routing function. On a localized, distributed and fully cached basis ENUM essentially becomes a Central Routing Server. One of the big holes in IMS BTW. Essentially an IP Service Control Point in old TDM/SS7 terms. ENUM did not fail .. e164.arpa failed. Like lots of IETF protocols they sometimes get use for things not originally intended. MIME immediately comes to mind. If I recall ENUM still baked into the IMS architecture. SIP Redirect also works well for number translation functions and modern database technology has made the difference in query response time negligible. It's now only a question of network preference on which protocol to use. There is a lot of real 6116 technology out there. Hadriel is right and Brian is simply wrong 6116 IS everywhere and it's baked into every SIP Session Border Controller sold on the Planet. There is no question you could develop some HTTPS like methodology that would equally well for number translations but as a practical matter it's simply a matter of taste. Provisioning is the larger problem and DRINKS is still at it after 4 years. Dan and Brian correctly points out one of the issues with a public tree was privacy. The idea that since the tree was public on the global Internet an enterprising Voice Spammer could scrape the tree to identify all active E.164 numbers. Brian's issue #6 is a not true since any US carrier for instance can actually see the underlying carrier number for any NANP number in the system. For other jurisdictions carrier identification in the underlying numbering databases is different. Obviously the #1 problem e164.arpa was the delegation model which required endless fights with the ITU which no one, I assume wants to repeat. Second the DNS is what it is, so you were left with no methodology for Authentication or Authorization of the query itself. In private instantiations this was solved by requiring VPN access even down to a limited set of IP addresses. It works if the application using 6116 was limited enough. IN the US this was done for the MMS mobile picture routing application and the FCC's own I-TRS database for the hearing impaired. Third ... one answer. In SIP call routing this posed a problem generally referred to Determinate Response. The target URI for the terminating Carrier SBC might be different based on who was asking the question and ultimately where. Obviously we got nowhere with Kaplan source URI though I understand it has been implemented in private ENUM instantiations. Private firms like Akamai munge DNS all the time in CDN networks to optimize the source of content to the location of the query. Fourth was the obvious political problem of having carriers agree to allow user control of routing data and that was a nonstarter. However if the tree was actually in control of the service providers ... gee GSMA Pathfinder.. well then that was NOOOOOO problem. But Pathfinder had its own set of issues. There were at least 2 other well-funded ENUM initiatives driven by carriers in the US alone, but in my judgment they have not deployed since the market conditions and requirements were not ready. In addition there are at least a dozen private ENUM services in existence. "Money is the answer what is the question?" Shockey's Law. http://www.gsma.com/technicalprojects/pathfinder That said the proposed requirements here are actually different and the market conditions have demonstrably changed so certainly 6116 technology COULD work but you would have to revisit a lot of issues like the E2MD problem etc Source URI and the provisioning issues. The interest of the carriers and the regulators are in actual alignment here. 6116 is a reasonable option that should be left on the table for consideration as the STIR process moves forward and the full requirements are actually understood. One of those is the structure for E.164 numbers controlled by Public Safety and Government authorities themselves. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dan York Sent: Thursday, June 13, 2013 8:52 AM To: Hadriel Kaplan Cc: stir@ietf.org; Stephen Farrell; Dave Crocker; Peterson, Jon; Henning Schulzrinne Subject: Re: [stir] current draft charter Hadriel, On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >That begs the question of what issues you think made Public ENUM fail, >and why we won't hit the same issues in whatever model we choose. Since you addressed this question to me, I feel compelled to answer... but in the meantime both Brian and Jon have given much more detailed answers with which I mostly agree. I saw security/privacy issues as the main issues that made Public ENUM not work, i.e. Brian's points 4, 5 and 6: > 4. Any public database that was able to show any information about a >telephone number was considered a privacy issue, requiring a lot of >"sign off", which never happened. > 5. Everyone objected to being able to determine what numbers were "live" > 6. Carriers objected to a public database that told competitors what >numbers they controlled The potential for spam was also high. Five or six years ago there was at least one tool circulating around that would walk an ENUM tree, generate a list of all potential phone numbers and then send SIP INVITEs to all of those numbers. I remember either seeing a video or reading about how someone did this with all the public ENUM numbers published for Germany (at that time). So using Public ENUM could be a fantastic way to potentially get yourself on the calling lists for telemarketers. Ideally, I think a public service *would* be a useful way to enable ubiquitous usage. I'm just not sure how to get there without also opening a solution up to these same kind of security/privacy issues. Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Thu Jun 13 10:18: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 82B5C21F9A12 for ; Thu, 13 Jun 2013 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 YivzTbn0DJzQ for ; Thu, 13 Jun 2013 10:18:31 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A83A821F99EE for ; Thu, 13 Jun 2013 10:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371143794; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=aCHZaVWZnn PjsxLPweYPbiwJ69KvISm7OmOYZKkB1Zk=; b=EXkpRWMTdCmnlDHgh7UWD3Qw93 R2z6fbTN86WjbRJHSeWCplfLE+1PD8YWUXzic5iE+PgAMWrtsROqz0D11W/g== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19493577; Thu, 13 Jun 2013 13:16:32 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 13 Jun 2013 13:18:13 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAAByyJ4AAC7aPAA== Date: Thu, 13 Jun 2013 17:18:12 +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.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: cOyCUNHNDTsMsME0LSHVCw== Content-Type: text/plain; charset="us-ascii" Content-ID: <1E4EA70C12CCC840AECE9900EC554C26@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker Subject: Re: [stir] current draft 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, 13 Jun 2013 17:18:35 -0000 > The liability you described above for ENUM is the same liability for >caller-id: we need the > carriers to agree to do this. The purpose of the proposed work is not to change or extend the authority of end users - and make no mistake, that was the purpose of public ENUM. Politically, that ambition was a significant barrier to carrier adoption. What we're proposing to do here instead is to leverage existing authority structures to the fullest capacity to increase the security of caller ID. There are roles carriers could play in this that would help, if they are interested and able. There are also techniques like iMessage that could help where carriers are not, or where things are just too early for carrier involvement. But I don't think this all reduces to just "we need the carriers to agree to do this," and nor that this has the same implications for carrier adoption that public ENUM did. Today there are use cases where carriers delegate some of their authority over numbers to entities like service bureaus or enterprises. Arguably, end users in many jurisdictions have certain authority over their numbers (like the authority to port) and in the future it's possible that regulators would broaden it. I can't readily speak to the question of whether or not carriers want to extend the authority of users over numbers except to say that some probably do and others probably don't. If we look at a service like Google Voice, say, and how carriers support that service, we can see at least some evidence for carriers who would benefit from increasing the authority of users in certain deployments. For the purposes of securing caller ID, I think activities at many of these different levels could be effective and that we shouldn't rule them out. > In what way is DNS with DNSSEC/DANE *not* a PKI? That is a fair question, I agree, and I don't mean to create some artificial distinction here. As I've suggested previously, I think the public DNS dictates a particular delegation and enrollment model for the pseudo-PKI that is DNSSEC/DANE. It may be that model is a fit for some of our use cases and not others. In any event, I think the charter and problem statement should be broad enough to encompass "key management" as Stephen suggested rather than limiting this to certificates. Jon Peterson Neustar, Inc. On 6/12/13 9:42 PM, "Hadriel Kaplan" wrote: > >On Jun 12, 2013, at 6:01 PM, "Peterson, Jon" >wrote: > >> It's always hard to say with any certainty why something failed. We can >> point to various causes and effects, one of which in this case certainly >> would be the difficulty of getting every world government to implement >>the >> system. ENUM was also designed from the start to empower end users to >> control how their numbers would be associated with Internet services, >>yet >> because of its built-in regulatory structures it required that >>empowerment >> to be driven by carriers with different interests. >>=20 >> But we don't even have to be asking ourselves about the relevance of >> public ENUM to the proposed work here in STIR unless we want to try to >> base everything on keying in the public DNS for telephone numbers. There >> are other models for this that don't have the liabilities I described >> above, anyway. > >The liability you described above for ENUM is the same liability for >caller-id: we need the carriers to agree to do this. We don't need *all* >of them to, at least not at the start, but we need a critical mass within >at least one country, preferably more than one country. Convincing just >Enterprises to do it is neither necessary nor sufficient. > > >> Keying in private DNS is more viable, for example. I think >> a PKI is more viable. > >In what way is DNS with DNSSEC/DANE *not* a PKI? > >-hadriel > From jon.peterson@neustar.biz Thu Jun 13 10: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 19ECB21F999C for ; Thu, 13 Jun 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 lFraO7PYAg2e for ; Thu, 13 Jun 2013 10:25:36 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0645F21F999B for ; Thu, 13 Jun 2013 10:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371144278; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=HUU689DaNb IxDV+OX3t/sE+hKe2Sq/XqLlJw78KbCms=; b=HMnv5XWWZ48zYp/tv0jy6kZdkY t34PNMAyX2FCUsKfzYs+XBrHUAsZwyvr6K2QB8tEujHEIJGMyUZMtaYQQnWQ== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20930347; Thu, 13 Jun 2013 13:24:37 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by stntexhc11.cis.neustar.com (10.31.58.70) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 13 Jun 2013 13:25:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Thu, 13 Jun 2013 13:25:27 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgA== Date: Thu, 13 Jun 2013 17:25:27 +0000 Message-ID: In-Reply-To: <51B94411.3090502@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: lDAyuFLI/Nmb6W7OA1JSlQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <9750AC34C6AE424F8379287696E250BC@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 13 Jun 2013 17:25:40 -0000 On 6/12/13 9:01 PM, "Dave Crocker" wrote: >On 6/12/2013 3:01 PM, Peterson, Jon wrote: >> But we don't even have to be asking ourselves about the relevance of >> public ENUM to the proposed work here in STIR unless we want to try to >> base everything on keying in the public DNS for telephone numbers. There >> are other models for this that don't have the liabilities I described >> above, anyway. Keying in private DNS is more viable, for example. I >>think >> a PKI is more viable. > > >Other models? I just meant for example private DNS, or PKI, as it says up there. >Is there a written description of the integrated query service that you >folks are considering, in terms of design, administration and operation? I wasn't talking about some kind of integrated query service, I was talking about where the keys should live. So, written descriptions would be CP/CPS sorts of things, if that's what you mean here? >It would help to also hear where such a design has already been >successfully deployed. Do you think that is an issue for CAs/PKIs? Certainly they have some rough edges, which is why we see the DNS (through DANE) potentially playing a role in their future. Or maybe it will be more like the SSL Observatory or any of several other private cert verification initiatives going around. I don't think I'm ready to give up entirely on the future of issuing certs - yet anyway. Jon Peterson Neustar, Inc. >As the Enum experience showed, schemes can be intelligent and appealing >but not succeed. So for any new deployment, any analysis needs to start >with skepticism and work its way up with pragmatics. > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From richard@shockey.us Thu Jun 13 10:51: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 9833521F9A0C for ; Thu, 13 Jun 2013 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.277, 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 pSgkLIK2DE5M for ; Thu, 13 Jun 2013 10:51:25 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 16F5C21F99F7 for ; Thu, 13 Jun 2013 10:51:25 -0700 (PDT) Received: (qmail 9153 invoked by uid 0); 13 Jun 2013 17:49:38 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 13 Jun 2013 17:49: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:To:From; bh=SvEEMjRXELV3vrxzl4/kn/53yyMsGeFW4YwVP+SljEc=; b=J0HkD14SvfN4Bp32b2xAIbEvFUFVh5STXYP8+B/Qv622VmAmQmIHnTAUxy+6wtw9dTxGnsvFuiwLGH2VfStWMpA29ISylLLVH4qz8MHFeT3K4L0yJQZiLuG7tAzF8xXo; Received: from [72.66.111.124] (port=52063 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UnBeU-00043n-0F for stir@ietf.org; Thu, 13 Jun 2013 11:49:38 -0600 From: "Richard Shockey" To: References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net> In-Reply-To: <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net> Date: Thu, 13 Jun 2013 13:49:34 -0400 Message-ID: <002c01ce685e$5e6f9ab0$1b4ed010$@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: AQHurB+rPvBwdWSMpuU+7zbFbFufQwKXAQNEAepiKvIBXaTXRAGgx24rmLdggrA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] current draft 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, 13 Jun 2013 17:51:30 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, June 13, 2013 12:52 PM To: Richard Shockey Cc: 'Wendt, Chris'; 'Dan York'; 'Peterson, Jon'; 'Hadriel Kaplan'; stir@ietf.org; 'Dave Crocker'; 'Stephen Farrell'; 'Henning Schulzrinne' Subject: Re: [stir] current draft charter This particular effort is aimed at trying to do something about robocalling, vishing and swatting in a relatively short time frame. To many of us, that seems doable. [RS> ] I agree. No argument there. Re-doing how routing of telephone number based identities work is the charter of TERQ. It probably can't be done relatively quickly, no matter what mechanisms are used. Restricting charter is a time-honored way of getting stuff done. I'll take that path without any qualms. I'm not interested in re-doing routing of telephone number identities as part of this work. [RS> ] [RS> ] but the practical issues of deployment are and that still is related which to what Chris and certainly Penn will constantly point out. What are the optimal structures for the databases and query mechanisms that do not necessarily require a 3 -7 year product cycle. That may actually be the national numbering databases where they exist. Focusing on one or two national use cases is in fact useful and as Penn correctly points out some LOST like structure over time could work for internationalizing the system. One thing would help is more data. It would be nice to hear from the Dutch COIN people, for instance since the structure of their LNP DB closely follows that of North American real time models. So is Ireland and ComReg I haven't monitored that stuff in years. The point of asserting that it takes someone like Neustar to handle a database like what is being described is that a DNS based tree doesn't map into the way number delegation works - so the entire tree has to be handled by one entity - you can't delegate part of it to someone else, especially when porting is considered. I was trying to contrast that with the model I've described where cert delegation follows number delegation. That doesn't require a monolithic database. [RS> ] [RS> ] You are really going to have to re explain that what you mean ENUM like delegation does not map into number delegation. Granted that having dealt with ENUM for as many years as I have may have totally dulled my synapses but you need to walk through that more carefully. Ok so walk me through how the Canadian NANP will be separated from the US NANP and individual Public Safety numbers will the separated from both. Brian On Jun 13, 2013, at 12:39 PM, Richard Shockey wrote: > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Thursday, June 13, 2013 10:08 AM > To: Wendt, Chris > Cc: Dan York; Peterson, Jon; Hadriel Kaplan; stir@ietf.org; Dave > Crocker; Henning Schulzrinne; Stephen Farrell > Subject: Re: [stir] current draft charter > > The IETF is starting a new effort on routing, see the TERQ work. If > you have ideas on routing, that would be the place to bring them. > [RS> ] > [RS> ] Wait a second.. You are demonstrating a profound > misunderstanding of what a service provider has in place or are > capable of actually implementing within a reasonable time frame. It > is not utterly unreasonable to at least consider that the issues of > number resolution for TN Source Authentication or Routing would be > somewhat similar. There is infrastructure and technology in place. Dismissing that question out of hand is absurd. > Frankly the way the IETF works these days the chances of TERQ actually > deploying before the End of Ages is debatable. You know the timelines > as well as anyone ... 4 years for a RFC then 2 years for it to show up > on carrier requirements, regression testing .. vendor selection. Get a grip. > > > I think the problem we have here is trying to decide who is a "good guy". > Most of the service providers who would would call "pink" in this > context would claim they are good guys. Trying to create a mechanism > to separate good guys from bad guys is very hard. > > I'm not sure why protecting TNs individually is more complex then the > view you have of routing, especially because we have tried what you > are suggesting, although we did not have DNSSEC. Dealing with the > privacy issues, just to start, would be the first real barrier. > > Let's say we got beyond that. We then need someone, probably someone > like Neustar, to maintain a per country portion of the database. How > would it do that? > > [RS> ] OH PLEASE.. I love a good global domination strategy as much > as the next red blooded capitalist but these endless references to > ..."somelike NeuStar" are becoming tedious and inappropriate. > > > Basically, every time a number was delegated, it would change the > domain of the entry to reflect the delegation. That could work. What > it means is that delegation of any kind has to be recorded in the new > database. If you note, certs follow delegation, with you inserting > "domain" in the middle (domain follows delegation). The twist is that > instead of a 2nd level reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes > to the new database and has them effectively do the same thing. > > Having databases that associate a domain with a TN might help things > like finding a cert, but it doesn't affect the basic issue of how you > avoid spoofing. Do you think the approach we have suggested here > (signing of From/To/Time/Session Id) with a cert traceable to the > identity is appropriate? > > If you are "simply" suggesting the cert is located via DANE in the > domain of the caller, then for user@domain, I think we're probably > saying the same thing. Where we seem to differ is that you suggest we > have a DNS entry for the TN that has the domain in it, and then you > use that to find the cert used for signing. In the basic case, we're > suggesting a URI to the cert in the signaling, which seems simpler. > What matters however is how the DNS tree for the TNs is maintained. > > So, my response is the same as I have given before: the privacy and > operational issues of putting per TN information in the public DNS are > overwhelming. We have tried it, and it has failed. > > Unlike Hadriel, you really do want to disclose domain with TN. That > has been a non-starter for many carriers. > > Brian > > > On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" > > wrote: > >> Hi Folks, >> >> I believe it couldn't be a better time to start discussing public routing. > While this is a little beyond the scope of protecting caller-id, I > think the effort is highly complimentary, and solving both together > will provide a better path to get things implemented in service provider networks. >> >> IP communications is evolving whether you want to get on the train or not. > I applaud Henning's efforts to push the ball forward. >> >> Moving more to an internet model for routing is inevitable, IMHO. >> There > is questions about how relevant TN is or will be in the near future. > For the sake of having any chance of success, let's simplify the > effort and focus on the future. There will be a transition process to > get there, no doubt, but let's focus on the end goal, and not focus on > fixing problems of the past. We are already in a world of multiple > private peering arrangements, LCR, and managing multiple egress points > anyway, so the transition should not be that difficult. >> >> I believe a common routing mechanism for both user@domain and TN/e164 > based identities should be the focus. Treat both as first class > citizens for IP communications. >> >> Use DNS and domain based routing for all. Use DNSEC to validate and > cryptographically associate TN/caller-id with a domain (for good guys) > and do domain routing from there. >> Forget about trying to protect TN's individually, that is too complex. >> >> It's up to the consumer service providers to enforce and block bad >> things > from bad domains. >> It's up to wholesale/trunking providers to allow customers to assert >> their > own domain, or be responsible for asserting domains on their behalf at > the risk of being considered a "bad guy". >> >> This is high level, and perhaps a sunny day view of the world, but I >> don't > think unrealistic. Frankly, if there is any chance of a common > federated communications system continuing to be relevant, I believe a > simple approach that matches the internet model is the only choice. >> >> You should see more concrete opinions from Comcast in the future, but >> I > wanted to take the opportunity to express these thoughts and would > love feedback on why this should or should not be the model going forward. >> >> If there is agreement, I believe some of this should be addressed in >> the > charter, because I think some of the assumptions may not enable this path. >> >> -Chris >> >> >> >> >> On Jun 13, 2013, at 8:51 AM, Dan York wrote: >> >>> Hadriel, >>> >>> On 6/12/13 5:38 PM, "Hadriel Kaplan" wrote: >>> >>>> That begs the question of what issues you think made Public ENUM >>>> fail, and why we won't hit the same issues in whatever model we choose. >>> >>> Since you addressed this question to me, I feel compelled to >>> answer... but in the meantime both Brian and Jon have given much >>> more detailed answers with which I mostly agree. >>> >>> I saw security/privacy issues as the main issues that made Public >>> ENUM not work, i.e. Brian's points 4, 5 and 6: >>> >>>> 4. Any public database that was able to show any information about >>>> a telephone number was considered a privacy issue, requiring a lot >>>> of "sign off", which never happened. >>>> 5. Everyone objected to being able to determine what numbers were "live" >>>> 6. Carriers objected to a public database that told competitors >>>> what numbers they controlled >>> >>> >>> The potential for spam was also high. Five or six years ago there >>> was at least one tool circulating around that would walk an ENUM >>> tree, generate a list of all potential phone numbers and then send >>> SIP INVITEs to all of those numbers. I remember either seeing a >>> video or reading about how someone did this with all the public ENUM >>> numbers published for Germany (at that time). So using Public ENUM >>> could be a fantastic way to potentially get yourself on the calling >>> lists > for telemarketers. >>> >>> Ideally, I think a public service *would* be a useful way to enable >>> ubiquitous usage. I'm just not sure how to get there without also >>> opening a solution up to these same kind of security/privacy issues. >>> >>> Dan >>> >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org +1-802-735-1624 >>> Jabber: york@jabber.isoc.org >>> Skype: danyork http://twitter.com/danyork >>> >>> http://www.internetsociety.org/deploy360/ >>> >>> _______________________________________________ >>> 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 br@brianrosen.net Thu Jun 13 11:16: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 5CF1E21F9A06 for ; Thu, 13 Jun 2013 11:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.169 X-Spam-Level: X-Spam-Status: No, score=-99.169 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_24=0.6, RDNS_NONE=0.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 Z8FocUKdanv6 for ; Thu, 13 Jun 2013 11:16:05 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2150C21F9A00 for ; Thu, 13 Jun 2013 11:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=rvaipqrsauc+oOOMBlHa6/+dGWlEslbbPb40t5h+s3A=; b=dwRtxExyu1v74i7GZh7WW8iDVM0HvTH3iLqbQ91nhBhLvhZWXHskYwvzJu7A5ITlrghKciScw+3AERXRJLNN7PyrUVf7Y5kStkRlmkMMi1yelGhKNJ6GGbKdAUy+FkXTJice0GUO+zfo9qlmv6QyH6ebGVrZXBubhkgy1fIVD3c=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42699 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UnC42-00075D-TP; Thu, 13 Jun 2013 14:16:02 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <002c01ce685e$5e6f9ab0$1b4ed010$@shockey.us> Date: Thu, 13 Jun 2013 14:16:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F5553F7-27FF-413D-BF1C-9E53411E32C5@brianrosen.net> References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net> <002c01ce685e$5e6f9ab0$1b4ed010$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org Subject: Re: [stir] current draft 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, 13 Jun 2013 18:16:10 -0000 > [RS> ] You are really going to have to re explain that what you mean = ENUM > like delegation does not map into number delegation. Granted that = having > dealt with ENUM for as many years as I have may have totally dulled my > synapses but you need to walk through that more carefully. Ok so = walk me > through how the Canadian NANP will be separated from the US NANP and > individual Public Safety numbers will the separated from both.=20 Number delegation is now, and increasingly moving to range sizes that = are not power of 10. Where you still get PA assignments in the US in 1000 number blocks, a = typical resell as likely 25 numbers or 5 as it is 100 or 10. The = latest moves in the US will force the PA to do small assignments also. Unless the delegation size is a power of 10, it doesn't map into the = delegation model of DNS with reverse-dotted zones. You end up fully populating the tree down to the full e.164, and = delegating multiples of 1 TN rather than being able to delegate a higher = level part of the tree. That is so unwieldy that you wouldn't do it - you get someone like = Neustar to maintain the entire tree and provide a provisioning interface = that handles an arbitrary sized delegation. We could still delegate the = NPAs out of +1 to the appropriate contractors on a per nation basis, but = of course, all of the nations that share +1 have to agree on a common = +1 domain operator. cc1enum anyone? anyone? Brian From richard@shockey.us Thu Jun 13 11:54: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 0E92221F8D90 for ; Thu, 13 Jun 2013 11:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=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 r79Zb-Igo7Fx for ; Thu, 13 Jun 2013 11:54:42 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id ECE3721F8D16 for ; Thu, 13 Jun 2013 11:54:41 -0700 (PDT) Received: (qmail 1434 invoked by uid 0); 13 Jun 2013 18:54:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 13 Jun 2013 18:54:19 -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=AK6Kzznmm2afRrAYqArqiWN3YvlF3dgKaeGSZ56gIJA=; b=DWQ9rBMB6UMn7ENrbqvzLOpRenERGuE5J87PKzJ6lgLRQVj55GYaGveqjhJEKc38imTSJhDDatb8XiRmnWAlSl0yLFOs/3YDmUUo76UnKcO1dt1Y17l7fnHVvpATXcC4; Received: from [72.66.111.124] (port=52823 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UnCf5-0003Xi-2b; Thu, 13 Jun 2013 12:54:19 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net> <002c01ce685e$5e6f9ab0$1b4ed010$@shockey.us> <5F5553F7-27FF-413D-BF1C-9E53411E32C5@brianrosen.net> In-Reply-To: <5F5553F7-27FF-413D-BF1C-9E53411E32C5@brianrosen.net> Date: Thu, 13 Jun 2013 14:54:15 -0400 Message-ID: <005b01ce6867$67ba8400$372f8c00$@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: AQHurB+rPvBwdWSMpuU+7zbFbFufQwKXAQNEAepiKvIBXaTXRAGgx24rAl6iwNQB/p6JRZiUjXTg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] current draft 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, 13 Jun 2013 18:54:47 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, June 13, 2013 2:16 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] current draft charter > [RS> ] You are really going to have to re explain that what you mean > ENUM like delegation does not map into number delegation. Granted that > having dealt with ENUM for as many years as I have may have totally dulled my > synapses but you need to walk through that more carefully. Ok so walk me > through how the Canadian NANP will be separated from the US NANP and > individual Public Safety numbers will the separated from both. Number delegation is now, and increasingly moving to range sizes that are not power of 10. Where you still get PA assignments in the US in 1000 number blocks, a typical resell as likely 25 numbers or 5 as it is 100 or 10. The latest moves in the US will force the PA to do small assignments also. Unless the delegation size is a power of 10, it doesn't map into the delegation model of DNS with reverse-dotted zones. You end up fully populating the tree down to the full e.164, and delegating multiples of 1 TN rather than being able to delegate a higher level part of the tree. [ [RS> ] Well what's wrong with TN level delegations? That is so unwieldy that you wouldn't do it - you get someone like Neustar to maintain the entire tree and provide a provisioning interface that handles an arbitrary sized delegation. We could still delegate the NPAs out of +1 to the appropriate contractors on a per nation basis, but of course, all of the nations that share +1 have to agree on a common +1 domain operator. cc1enum anyone? anyone? Brian _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc2@dcrocker.net Thu Jun 13 15: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 DDFC021F9B1C for ; Thu, 13 Jun 2013 15:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J83LtCfnfWr8 for ; Thu, 13 Jun 2013 15:24:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EB62621F8B21 for ; Thu, 13 Jun 2013 15:24:26 -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 r5DMONCo003265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 15:24:26 -0700 Message-ID: <51BA468F.5020105@dcrocker.net> Date: Thu, 13 Jun 2013 15:24:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 13 Jun 2013 15:24:26 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 13 Jun 2013 22:24:32 -0000 Jon, et al, On 6/13/2013 10:25 AM, Peterson, Jon wrote: > On 6/12/13 9:01 PM, "Dave Crocker" wrote: > >> On 6/12/2013 3:01 PM, Peterson, Jon wrote: >>> But we don't even have to be asking ourselves about the relevance of >>> public ENUM to the proposed work here in STIR unless we want to try to >>> base everything on keying in the public DNS for telephone numbers. There >>> are other models for this that don't have the liabilities I described >>> above, anyway. Keying in private DNS is more viable, for example. I >>> think >>> a PKI is more viable. >> >> >> Other models? > > I just meant for example private DNS, or PKI, as it says up there. 1. The functional description that's been offered said that validation is to be permitted by entities such as callee-side enterprises and even callee UAs. That precludes any sort of private service. Whatever parameters must be obtained outside of the SIP headers -- such as public keys -- they need to be publicly accessible. 2. From one of your earlier notes, I gather that by "PKI" you mean the bushy (multi-root) system that operates for SSL/TLS web services? You appear to be using PKI to mean a specific, integrated, operating credential service, so I would like to be clear about which specific one you mean; the one used by the Web seems to be it? >> Is there a written description of the integrated query service that you >> folks are considering, in terms of design, administration and operation? > > I wasn't talking about some kind of integrated query service, I was > talking about where the keys should live. So, written descriptions would > be CP/CPS sorts of things, if that's what you mean here? I suspect you mean more than where they live, since they aren't much use if they can't be retrieved, and in fact retrieved publicly. By "query service" I meant the term generically as a mechanism that askes for something and gets it. I didn't want to imply or constrain any details about the form of the request or what was returned; merely that it's in the service of performing validation. Since the intent here is to develop a global validation service for SIP-based calls and since such a service will need to obtain some types of information to permit validation, it will need a mechanism for retrieving whatever that information is. That's all I meant by query service. While yes, one can imagine designing a service that permits packaging everything in-line with the SIP data, it's clear that that won't be sufficient, based on one or more of the documents -- and much of the message postings -- for this topic. Hence, it needs a query service of some sort. >> It would help to also hear where such a design has already been >> successfully deployed. > > Do you think that is an issue for CAs/PKIs? Certainly they have some rough The PKI service used for the web has the advantage of existing and being heavily used. A base of experience is goodness, when considering out-sourcing a component of a new service. Whether its characteristics suffice for the current project, I don't know. Some times, rough edges cut thing and bleed them dry. > edges, which is why we see the DNS (through DANE) potentially playing a Ah yes, the great promise of DANE. I'm sure it will yet deliver, as have all of the other promising efforts in the IETF. Oh, no, this one really will. No, honest, it will. And I hope I'm serious. That's not a criticism of DANE. It's an attempt to raise a flag about relying on it. One of the classic errors in a new project is creating a critical dependency on a parallel, independent project. Sometimes it's necessary, but it's always extremely risky. Extremely. Always. > role in their future. Or maybe it will be more like the SSL Observatory or The 'maybe' -- and equivalent phrasings that you've used -- point up something that I've become confused about. What I was told (rather forcefully offline) is that there is a solution already formulated. However what's been put forward on the list so far sounds more like some ideas, at least some of which are not yet close to being solid. If there is in fact a concrete, detailed design already in hand, that attends to relevant security, privacy, scaling, deployment, administration and operations issues, let's hear it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hgs@cs.columbia.edu Thu Jun 13 18: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 4624021F9AB4 for ; Thu, 13 Jun 2013 18:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 sDDlMO3Q0nby for ; Thu, 13 Jun 2013 18:12:55 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB5621F9A76 for ; Thu, 13 Jun 2013 18:12:55 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5E1CmcK028173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Jun 2013 21:12:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Thu, 13 Jun 2013 21:12:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> References: To: Dan York X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 14 Jun 2013 01:13:01 -0000 Instead of looking at this as an ENUM-like problem, another angle is to = consider this somewhat similar to the whois issue. Also, I suspect there would be fewer concerns if the DNS-like database = mainly referred to other databases, which can then be access-controlled = as needed, and can evolve. This model might also allow for combining the = CDS-like approach with the PKI approach for the same number, and allow = for multiple operators for both models. The DNS (or similar) public = database would only indicate which methods the number supports and = redirect to the rendezvous or PKI service. I'm not sure that qualifies = as DANE-like. My general gut feeling is that we don't guess well on how public = infrastructure evolves (or doesn't), so allowing for multiple outcomes = and abstracting it, as well as allowing for functionality that gets = better over time, might be more productive, as this allows for partial = success, rather than just "exactly as planned" or "complete failure". Also, keeping scale in mind helps: In our case, the scale for = "number-holding service providers" is currently a few thousand, not = millions, so management solutions that don't scale to millions are = acceptable to get started. The backend process today is pretty manual = (faxes, web pages and proprietary APIs), so expectations are fairly low. Henning On Jun 12, 2013, at 4:40 PM, Dan York wrote: > On 6/12/13 2:22 PM, "Peterson, Jon" wrote: >=20 >=20 >> Agreed. Though I do think that even for the domain model, we could = get >> some value from looking at DANE to improve the way that credentials = are >> managed. Whether we put the keys in the DNS or just point to the = approved >> cert by reference, we should probably have some means for the = successor to >> RFC4474 Identity-Info to tip off relying parties to DANE. >=20 > Agreed (as you would expect me to say). I've been thinking about how = DANE > could help here, but... >=20 >> But yes, for the telephone model it seems unlikely that casting these = as >> domain names will get us very far. >=20 > ... I think this issue will get in the way right now. As much as I = would > love to see this as a good example of where DANE can help, I still = haven't > been able to wrap my brain around how we could use DNS for telephone > numbers without running into all the exact same issues that made = public > ENUM non-deployable. :-( >=20 > I agree, though, that it would be helpful to have some way for a = header to > alert relying parties to DANE in the event that there is a way it can = work. >=20 > Dan >=20 >=20 From jon.peterson@neustar.biz Thu Jun 13 18:58: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 8E03121F9B06 for ; Thu, 13 Jun 2013 18:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 eeRF02E42EtN for ; Thu, 13 Jun 2013 18:58:54 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4892221F9AFE for ; Thu, 13 Jun 2013 18:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371175021; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=1u5O5kt69/ nrgUXy64Lx60Weq3FdxeA9jZxSc5O5pcY=; b=ZEUUGkbexpOVsYcBtOvAm584JL W/zxtj7NQ/k7vb6rJyH3bjUXDO8LxIPsZbS67xJqJMaEuGSZRUQ06rCuhf0g== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19514342; Thu, 13 Jun 2013 21:57:00 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by stntexhc12.cis.neustar.com (10.31.58.71) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 13 Jun 2013 21:58:45 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Thu, 13 Jun 2013 21:58:43 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoA= Date: Fri, 14 Jun 2013 01:58:42 +0000 Message-ID: In-Reply-To: <51BA468F.5020105@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.117] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oMOI2wWnEzgsbQDUmfUXIA== Content-Type: text/plain; charset="us-ascii" Content-ID: <52C9941E481D024EA6C0CAF4B142DBCA@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 14 Jun 2013 01:58:58 -0000 Inline below. On 6/13/13 3:24 PM, "Dave Crocker" wrote: >Jon, et al, > > >On 6/13/2013 10:25 AM, Peterson, Jon wrote: >> On 6/12/13 9:01 PM, "Dave Crocker" wrote: >> >>> On 6/12/2013 3:01 PM, Peterson, Jon wrote: >>>> But we don't even have to be asking ourselves about the relevance of >>>> public ENUM to the proposed work here in STIR unless we want to try to >>>> base everything on keying in the public DNS for telephone numbers. >>>>There >>>> are other models for this that don't have the liabilities I described >>>> above, anyway. Keying in private DNS is more viable, for example. I >>>> think >>>> a PKI is more viable. >>> >>> >>> Other models? >> >> I just meant for example private DNS, or PKI, as it says up there. > >1. The functional description that's been offered said that validation >is to be permitted by entities such as callee-side enterprises and even >callee UAs. That precludes any sort of private service. Whatever >parameters must be obtained outside of the SIP headers -- such as public >keys -- they need to be publicly accessible. Potentially, yes, callee-side enterprises and even callee UAs would be able to validate. The original RFC4474 model describes an abstract "verification service" function that can be performed either by an intermediary or an endpoint. I've been assuming we'd retain that architecture. The RFC4474 model also has the concept that a URI is carried alongside the signature, in a separate header called Identity-Info, to designate the credential that was used to generate the signature. So yes, any verification service needs to be able to resolve that URI, so it must be public in at least that sense (and the verification service must trust whatever trust anchor generated the credential on the other side of that URI too). IF we were to transpose this to a DNS-like model, presumably the Identity-Info header or its successor would be extended in some fashion to allow it to designate that the DNS should be consulted. >2. From one of your earlier notes, I gather that by "PKI" you mean the >bushy (multi-root) system that operates for SSL/TLS web services? You >appear to be using PKI to mean a specific, integrated, operating >credential service, so I would like to be clear about which specific one >you mean; the one used by the Web seems to be it? I mean a system that resembles that "bushy" system, yes. I imagine it could encompass multiple roots. The secure-origins-ps document does however contain some text to the effect that it would be real nice if we could avoid having different roots claiming authority over the same name, though, given what the consequences of that have been for web PKI. And by PKI I here I'm not sure I mean any specific, integrated, operating credential service as such, though certainly one that would use technical components familiar to anyone who was familiar with web PKI. > >>> Is there a written description of the integrated query service that you >>> folks are considering, in terms of design, administration and >>>operation? >> >> I wasn't talking about some kind of integrated query service, I was >> talking about where the keys should live. So, written descriptions would >> be CP/CPS sorts of things, if that's what you mean here? > >I suspect you mean more than where they live, since they aren't much use >if they can't be retrieved, and in fact retrieved publicly. Right, no, as I said above I was assuming something like Identity-Info from RFC4474 would be available to facilitate retrieval. >By "query service" I meant the term generically as a mechanism that >askes for something and gets it. I didn't want to imply or constrain any >details about the form of the request or what was returned; merely that >it's in the service of performing validation. Sure, as specified in RFC4474, https or even cid (to designate a multipart MIME body attached to the request) are examples of how the credential fetch would happen. It is definitely in the scope of proposed work to expand those options. >Since the intent here is to develop a global validation service for >SIP-based calls and since such a service will need to obtain some types >of information to permit validation, it will need a mechanism for >retrieving whatever that information is. That's all I meant by query >service. Sure, agreed, we're on the same page. >While yes, one can imagine designing a service that permits packaging >everything in-line with the SIP data, it's clear that that won't be >sufficient, based on one or more of the documents -- and much of the >message postings -- for this topic. Hence, it needs a query service of >some sort. Gotcha. >>> It would help to also hear where such a design has already been >>> successfully deployed. >> >> Do you think that is an issue for CAs/PKIs? Certainly they have some >>rough > >The PKI service used for the web has the advantage of existing and being >heavily used. A base of experience is goodness, when considering >out-sourcing a component of a new service. Whether its characteristics >suffice for the current project, I don't know. Some times, rough edges >cut thing and bleed them dry. Like I said, I'd hope we could benefit from some of the operational lessons of web PKI while still retaining the tried and true technologies that have succeeded here. > >> edges, which is why we see the DNS (through DANE) potentially playing a > >Ah yes, the great promise of DANE. I'm sure it will yet deliver, as >have all of the other promising efforts in the IETF. Oh, no, this one >really will. No, honest, it will. And I hope I'm serious. >That's not a criticism of DANE. It's an attempt to raise a flag about >relying on it. > >One of the classic errors in a new project is creating a critical >dependency on a parallel, independent project. Sometimes it's >necessary, but it's always extremely risky. Extremely. Always. I want to make an allowance for DANE, especially where it can help with greenfield SIP URIs rather than telephone numbers (e.g. Which cert should I trust for sip:jon@example.com?). I do have some sense of the state of DANE adoption, and I've certainly heard pushback from browser vendors and others about its mid-term prospects. But DANE wouldn't play a role in our story about how credentials are managed for TNs unless of course we assume some ENUM-like TN hierarchy in the DNS is a part of this key management solution. >> role in their future. Or maybe it will be more like the SSL Observatory >>or > >The 'maybe' -- and equivalent phrasings that you've used -- point up >something that I've become confused about. What I was told (rather >forcefully offline) is that there is a solution already formulated. >However what's been put forward on the list so far sounds more like some >ideas, at least some of which are not yet close to being solid. Um. In so far as there is IETF work already formulated, as far as I know it's what's captured in the various drafts under discussion. I would say you can judge for yourself how baked those ideas are. We have two proposed areas of IETF work, one on providing a better in-band identity indication in SIP, and another (more ambitious) effort to work on an out-of-band solution.=20 Both have some dependency on credentials which capture authority over telephone numbers. The degree to which those credentials are a subject of IETF work is less obvious to me. Let's assume we're talking about a PKI, for the moment. In the web world, we have RFCs that talk about how you need to process certs to make web security work, what information needs to be in them and where it lives, and that is all clearly IETF work. But we don't have RFCs that constrain the set of CAs to any particular vendor(s) or that overly prescribe their operational environment, like how a CA enrolls customers or sorts them into levels of assurance, say. So right now in the proposed charter there is a placeholder for a document that would cover the sorts of things about the key management system that would be in the scope of the IETF, to foster interoperability of signers and verifiers. I think we'd need to know more about where we're going before I could tell you in more detail what the document would contain. So yeah, a lot of things are not solid at this stage. >If there is in fact a concrete, detailed design already in hand, that >attends to relevant security, privacy, scaling, deployment, >administration and operations issues, let's hear it. For what part of the work? But I guess whichever part you mean, I don't think having a document with that level of detail in hand is necessary to charter this proposed work or to set a direction for it. If we assume the two main key management options here are something like the DNS (public or private, with or without DNSSEC/DANE) and something like a web PKI, I think both are fairly well understood in the dimensions you describe here. I would be hesitant to explore options where that didn't seem to be case. Jon Peterson Neustar, Inc. >d/ > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From richard@shockey.us Fri Jun 14 15:10: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 ADFF521F9ABB for ; Fri, 14 Jun 2013 15:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.312, 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 1dzUIZ7opwV3 for ; Fri, 14 Jun 2013 15:10:26 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id C8ACD21F9AAD for ; Fri, 14 Jun 2013 15:10:25 -0700 (PDT) Received: (qmail 24406 invoked by uid 0); 14 Jun 2013 22:05:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 14 Jun 2013 22:05:07 -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=djil6PfACX+puolLljJqkIgZE5omriqAMQG+2UOcH7k=; b=gzBtHmJizViZXh6Z/zBv5S3sR6uevmtpE4ACmZGaTjg4XNrqsxM+nr8m6dipKuGKn/YBskQ3WXSUpHZC9T+ZazyXM0N1XEzmR72ffcTQ8CPg5ZROji55W3q8jkC9qT7h; Received: from [72.66.111.124] (port=54075 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Unc7G-0003AO-Il; Fri, 14 Jun 2013 16:05:06 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Dan York'" References: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> In-Reply-To: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> Date: Fri, 14 Jun 2013 18:05:02 -0400 Message-ID: <01cc01ce694b$391898a0$ab49c9e0$@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: AQIXky4FP44qPRG7y+/mn9A2J1JF1QIDKzFymJNO7UA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 14 Jun 2013 22:10:30 -0000 In line -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, June 13, 2013 9:13 PM To: Dan York Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases Instead of looking at this as an ENUM-like problem, another angle is to consider this somewhat similar to the whois issue. Also, I suspect there would be fewer concerns if the DNS-like database mainly referred to other databases, which can then be access-controlled as needed, and can evolve. This model might also allow for combining the CDS-like approach with the PKI approach for the same number, and allow for multiple operators for both models. The DNS (or similar) public database would only indicate which methods the number supports and redirect to the rendezvous or PKI service. I'm not sure that qualifies as DANE-like. [RS> ] For what it's worth several of the designs for Carrier 6116 systems relied specifically on this model where the tree was essentially a "thin registry" and the E2U functions relied on NS records of one form or another to indicate a level of redirection where the carrier of record (or whomever) for a TN was presumed authoritative and you could also use other protocol methodologies like HTTPS for access control. The other model assumed the "thick registry" where indirection was not present and it more closely resembled a CDB model like the NPAC where the registry preformed the role of validating the provisioning and the URI data was ultimately "pushed" into the carrier networks or was available through other means to smaller carriers by whatever protocol method they choose 6116, SIP Redirect so long as they were able to be "certified" for access as a" licensed" user etc. I'll say it again if we deal with Telephony carriers provisioning within OSS/BSS systems has to be taken into account. In the US that is, I think 700 Million or so assigned TN's It would be easy for some folks to check with the NANPA Administrator to find out how many are actually active. I'm not saying STIR should go down this path only that that idea has had some serious proposals associated with it. My general gut feeling is that we don't guess well on how public infrastructure evolves (or doesn't), so allowing for multiple outcomes and abstracting it, as well as allowing for functionality that gets better over time, might be more productive, as this allows for partial success, rather than just "exactly as planned" or "complete failure". Also, keeping scale in mind helps: In our case, the scale for "number-holding service providers" is currently a few thousand, not millions, so management solutions that don't scale to millions are acceptable to get started. The backend process today is pretty manual (faxes, web pages and proprietary APIs), so expectations are fairly low. [RS> ] [RS> ] +1 to that ... Henning On Jun 12, 2013, at 4:40 PM, Dan York wrote: > On 6/12/13 2:22 PM, "Peterson, Jon" wrote: > > >> Agreed. Though I do think that even for the domain model, we could >> get some value from looking at DANE to improve the way that >> credentials are managed. Whether we put the keys in the DNS or just >> point to the approved cert by reference, we should probably have some >> means for the successor to >> RFC4474 Identity-Info to tip off relying parties to DANE. > > Agreed (as you would expect me to say). I've been thinking about how > DANE could help here, but... > >> But yes, for the telephone model it seems unlikely that casting these >> as domain names will get us very far. > > ... I think this issue will get in the way right now. As much as I > would love to see this as a good example of where DANE can help, I > still haven't been able to wrap my brain around how we could use DNS > for telephone numbers without running into all the exact same issues > that made public ENUM non-deployable. :-( > > I agree, though, that it would be helpful to have some way for a > header to alert relying parties to DANE in the event that there is a way it can work. > > Dan > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Sat Jun 15 11:57: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 B7F7E21F9E05 for ; Sat, 15 Jun 2013 11:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 eleMYgwCWF6Q for ; Sat, 15 Jun 2013 11:57:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4B18E21F9DFE for ; Sat, 15 Jun 2013 11:57:03 -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 r5FIusoZ032395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Jun 2013 18:56: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 r5FIutIl010900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jun 2013 18:56:55 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 r5FIusrT022705; Sat, 15 Jun 2013 18:56:54 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-189-250.vpn.oracle.com (/10.154.189.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jun 2013 11:56: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: Date: Sat, 15 Jun 2013 14:56:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Dave Crocker , Brian Rosen Subject: Re: [stir] current draft 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, 15 Jun 2013 18:57:08 -0000 On Jun 12, 2013, at 7:46 PM, "Peterson, Jon" = wrote: > The proposed STIR charter outlines two ways to secure identity: an = in-band > and an out-of-band approach. Discussion so far on this list has = focused > largely on the in-band. For the out-of-band approach, we need to be = able > to explore credentials whose authority rests on some other means than > delegation from on high: perhaps, like in ViPR, from probing how = numbers > are routed and using this to prove possession of the number. If you mean check return routability, Dan Wing had a draft on a = return-routability check: http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01 Unfortunately, legitimate caller-ids are sourced by elements/entities = that are not necessarily the same ones used for reaching the same number = back. For example the call-center scenarios, or doctor cellphone = scenario, or even Skype-out scenario. With regard to ViPR, I was under the impression ViPR's entire foundation = for trust authority rested on the PSTN, with the original PSTN call and = its caller-ids being part of the shared secret for later use in ViPR = peer discovery and authentication. If the caller-id's in the PSTN can = be faked, ViPR would have been in very big trouble, because it would = have enabled incorrectly finding and authenticating a malicious peer for = that spoofed number and making all future calls back to that malicious = peer for the number. No? (maybe ViPR changed after I stopped following = it) -hadriel From hadriel.kaplan@oracle.com Sat Jun 15 12:06: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 8BFA521F9D9D for ; Sat, 15 Jun 2013 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 tJIFO8tzWvPj for ; Sat, 15 Jun 2013 12:06:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 051C121F9B22 for ; Sat, 15 Jun 2013 12:06:28 -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 r5FJ6KKn024799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Jun 2013 19:06:21 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 r5FJ6JM5021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jun 2013 19:06:20 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5FJ6Ji7001734; Sat, 15 Jun 2013 19:06:19 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-189-250.vpn.oracle.com (/10.154.189.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jun 2013 12:06:19 -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: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> Date: Sat, 15 Jun 2013 15:06:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com> References: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org, Dan York Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 15 Jun 2013 19:06:35 -0000 On Jun 13, 2013, at 9:12 PM, Henning Schulzrinne = wrote: > Also, I suspect there would be fewer concerns if the DNS-like database = mainly referred to other databases, which can then be access-controlled = as needed, and can evolve. But that's just moving the problem around, isn't it? I mean ultimately some of us might want to actually implement the = signing and verification into our systems. If it uses public-key = signatures, then we need a standardized protocol by which our systems = can query for a certificate signed by some authority we trust for a = given E.164 number. If DNS tells us "go look over at FOO": then what = standardized protocol does FOO use that we need to implement? why should = we trust it for this caller-id? and how does it avoid the privacy = problems and ownership problems and so on? How do you even know we can = reach FOO, if it's not necessarily publicly reachable? I mean all I've heard is this:=20 Step-1) Some magic happens somewhere, to enable the caller to generate a = HTTP URL anyone can use** Step-2) You get the HTTP URL in SIP from the caller through some chain = of providers Step-3) You send a GET request to above URL Step-4) Some more magic happens** Step-5) You get back a magic certificate Step-6) You trust the magic was real, and use the cert to verify Step-7) Ta-da! You've now verified the caller-id! Step-8) Profit. **note: please contact the universal magician so we can make the magic = stuff happen for you and everyone else. > My general gut feeling is that we don't guess well on how public = infrastructure evolves (or doesn't), so allowing for multiple outcomes = and abstracting it, as well as allowing for functionality that gets = better over time, might be more productive, as this allows for partial = success, rather than just "exactly as planned" or "complete failure". I agree - we (the IETF) don't guess well on those things; we do much = better if there's an existing solution we're asked to improve or = standardize. ISTM usually IETF BOFs for new work are more successful if = they can point to existing proprietary solutions and say "see, it's = possible". But I don't think we have that for this work, do we? So I = think we have to discuss how such a thing would be possible, to assure = ourselves we're not going to be wasting time. > Also, keeping scale in mind helps: In our case, the scale for = "number-holding service providers" is currently a few thousand, not = millions, so management solutions that don't scale to millions are = acceptable to get started. The backend process today is pretty manual = (faxes, web pages and proprietary APIs), so expectations are fairly low. See, that matches up well with DNS too! The backend management/admin = process is pretty manual afaict. ;) -hadriel From dhc2@dcrocker.net Sun Jun 16 09: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 3395C21F9C42 for ; Sun, 16 Jun 2013 09:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=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 7wUETmmIYQKb for ; Sun, 16 Jun 2013 09:38:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 262D121F9C3B for ; Sun, 16 Jun 2013 09:38:43 -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 r5GGcdD7016657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 09:38:42 -0700 Message-ID: <51BDEA03.90808@dcrocker.net> Date: Sun, 16 Jun 2013 09:38:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 16 Jun 2013 09:38:42 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 16:38:48 -0000 On 6/13/2013 6:58 PM, Peterson, Jon wrote: > On 6/13/13 3:24 PM, "Dave Crocker" wrote: >> On 6/13/2013 10:25 AM, Peterson, Jon wrote: >>> I just meant for example private DNS, or PKI, as it says up there. >> >> 1. The functional description that's been offered said that validation >> is to be permitted by entities such as callee-side enterprises and even >> callee UAs. That precludes any sort of private service. ... > Potentially, yes, callee-side enterprises and even callee UAs would be > able to validate. OK. Again: No "private" mechanisms. > The original RFC4474 model describes an abstract > "verification service" function that can be performed either by an > intermediary or an endpoint. I've been assuming we'd retain that > architecture. RFC 4474 has been standards track for 7 years; that's a long time. What is its level of operational deployment and use, so far? If the answer is "not much", then it's not clear that automatically invoking its application here is as comforting or facilitative as one might wish... The cornerstone of RFC 4474 is an (independent) authentication service. Where are it's details specified? (Note that you correctly described RFC 4474 as describing an abstract service; that begs the question of the concrete details for its cornerstone. I'm also therefore assuming that Section 5 of that document is not the concrete service protocol details, since it's far from complete, in spite of having quite a bit of detail. A telling example is the text in Step 2: "Some possible ways in which this authentication might be performed include:") If I understand the RFC 4474 model correctly, a validated Identity field has the semantics of asserting that the From field is valid. So the assertion is not limited to the owner of the From field value. Correct? While such a model is understandable, it dramatically increases the reputation-management complexity of the task. I'm not aware of an extant service over the public Internet of similar complexity. Better still is that it's the entity making the assertion that tells the verifier where to look for verification information... What's seems to be missing from the text in RFC 4474 is how the verifier can tell whether the credential is a valid authorization for use of the From field value. (If it wasn't clear before, now you can understand why I'm curious about the concrete details of this authentication service.) > The RFC4474 model also has the concept that a URI is carried alongside the > signature, in a separate header called Identity-Info, to designate the > credential that was used to generate the signature. So yes, any > verification service needs to be able to resolve that URI, so it must be > public in at least that sense (and the verification service must trust > whatever trust anchor generated the credential on the other side of that "in that sense"? What other sense is possible and plausible? Perhaps I missed the details about the credential use that are specific to this application. Where are they provided, so that it's possible to tell how the credential is applicable for authorization validation? (Naive question: Are the details of the referenced URI use for credential acquisition sufficient and well-deployed? It's a significant protocol mechanism for this service and I'm not clear that it's the mechanism or its semantics are standard practice.) > URI too). IF we were to transpose this to a DNS-like model, presumably the > Identity-Info header or its successor would be extended in some fashion to > allow it to designate that the DNS should be consulted. This being a global, public, integrated query service, and the track record of deploying such things being highly discouraging, it's definitely good to stay with a proven, deployed service. That's why I asked after the experience with the independent authentication service specified in RFC 4474. >> 2. From one of your earlier notes, I gather that by "PKI" you mean the >> bushy (multi-root) system that operates for SSL/TLS web services? You >> appear to be using PKI to mean a specific, integrated, operating >> credential service, so I would like to be clear about which specific one >> you mean; the one used by the Web seems to be it? > > I mean a system that resembles that "bushy" system, yes. I imagine it "Resembles" implies that it doesn't exist yet. So it's subject to whatever challenges any other proposal must address. > could encompass multiple roots. The secure-origins-ps document does > however contain some text to the effect that it would be real nice if we > could avoid having different roots claiming authority over the same name, > though, given what the consequences of that have been for web PKI. That mostly says that the reality of this mechanism hasn't been established yet. If it had, we'd know whether it had multiple roots and whether that approach scaled well. The use of a multiple roots model for web validation is already showing some signs of stress. >> By "query service" I meant the term generically as a mechanism that >> askes for something and gets it. I didn't want to imply or constrain any >> details about the form of the request or what was returned; merely that >> it's in the service of performing validation. > > Sure, as specified in RFC4474, https or even cid (to designate a multipart > MIME body attached to the request) are examples of how the credential > fetch would happen. It is definitely in the scope of proposed work to > expand those options. https is not a query service. In this context, it is at most a transport service, that might have a query protocol running on top of it. >>>> It would help to also hear where such a design has already been >>>> successfully deployed. >>> >>> Do you think that is an issue for CAs/PKIs? Certainly they have some >>> rough >> >> The PKI service used for the web has the advantage of existing and being >> heavily used. A base of experience is goodness, when considering >> out-sourcing a component of a new service. Whether its characteristics >> suffice for the current project, I don't know. Some times, rough edges >> cut thing and bleed them dry. > > Like I said, I'd hope we could benefit from some of the operational > lessons of web PKI while still retaining the tried and true technologies > that have succeeded here. Operational lessons abound. Globally viable query services that are applicable to real-time use do not. To date, the Web's PKI's has seen extremely narrow success. The biggest lesson to take from a mechanism intended to be so flexible, after this long, is that the continuing narrowness of current use should be a caution. >>> edges, which is why we see the DNS (through DANE) potentially playing a >> >> Ah yes, the great promise of DANE. I'm sure it will yet deliver, as >> have all of the other promising efforts in the IETF. Oh, no, this one >> really will. No, honest, it will. And I hope I'm serious. ... > But DANE wouldn't play a role in our story about how credentials are > managed for TNs unless of course we assume some ENUM-like TN hierarchy in > the DNS is a part of this key management solution. Ok. So it's /not/ "potentially playing a role" for this discussion. > Um. In so far as there is IETF work already formulated, as far as I know > it's what's captured in the various drafts under discussion. ... > Both have some dependency on credentials which capture authority over > telephone numbers. Unless I've missed something, this translates into creation of a new global PKI service for authorizing third-party validation of number use. (The third-party aspect refers to the use of the Identity field I cited above.) That's pretty ambitious, especially in terms of OA&M, nevermind viable trust/reputation. > The degree to which those credentials are a subject of > IETF work is less obvious to me. Let's assume we're talking about a PKI, > for the moment. In the web world, we have RFCs that talk about how you > need to process certs to make web security work, what information needs to > be in them and where it lives, and that is all clearly IETF work. But we > don't have RFCs that constrain the set of CAs to any particular vendor(s) > or that overly prescribe their operational environment, like how a CA > enrolls customers or sorts them into levels of assurance, say. Nevermind the IETF. Credentials are at the heart of your proposal for this globally-integrated authorization service. So the details had better be specified and reviewed somewhere. > So right now in the proposed charter there is a placeholder for a document > that would cover the sorts of things about the key management system that > would be in the scope of the IETF, to foster interoperability of signers > and verifiers. "Foster" suggests that the service could be viable without that interoperability being standardized? > I think we'd need to know more about where we're going > before I could tell you in more detail what the document would contain. So > yeah, a lot of things are not solid at this stage. > >> If there is in fact a concrete, detailed design already in hand, that >> attends to relevant security, privacy, scaling, deployment, >> administration and operations issues, let's hear it. > > For what part of the work? Any of it. As I said, I had been told private and rather forcefully that this effort already had a solution in hand. I'm trying to re-gauge things, now that's it's clear that none of the details are actually worked out yet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Sun Jun 16 10:39: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 9DDD921F9D12 for ; Sun, 16 Jun 2013 10:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 rAaFsyPSPB-J for ; Sun, 16 Jun 2013 10:39:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id BE71721F9D14 for ; Sun, 16 Jun 2013 10:39:08 -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 r5GHd1PI026037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Jun 2013 17:39:01 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 r5GHd22i023614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 17:39:03 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5GHd2JC023490; Sun, 16 Jun 2013 17:39:02 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-164-181.vpn.oracle.com (/10.154.164.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Jun 2013 10:39:02 -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: <51BDEA03.90808@dcrocker.net> Date: Sun, 16 Jun 2013 13:39:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> References: <51BDEA03.90808@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 17:39:19 -0000 On Jun 16, 2013, at 12:38 PM, Dave Crocker wrote: > RFC 4474 has been standards track for 7 years; that's a long time. >=20 > What is its level of operational deployment and use, so far? If the = answer is "not much", then it's not clear that automatically invoking = its application here is as comforting or facilitative as one might wish=85= The answer is less than "not much"... more like "not at all". I'd argue the reasons it has never been deployed are: (1) people didn't = believe there was an identity spoofing problem yet, (2) it only really = validates email-style identities such as alice@foo.com, not E.164 = numbers, and (3) it's not deployable due to B2BUAs changing the fields = it would sign. > If I understand the RFC 4474 model correctly, a validated Identity = field has the semantics of asserting that the =46rom field is valid. So = the assertion is not limited to the owner of the =46rom field value. = Correct? While such a model is understandable, it dramatically = increases the reputation-management complexity of the task. I'm not = aware of an extant service over the public Internet of similar = complexity. >=20 > Better still is that it's the entity making the assertion that tells = the verifier where to look for verification information... What's seems = to be missing from the text in RFC 4474 is how the verifier can tell = whether the credential is a valid authorization for use of the =46rom = field value. (If it wasn't clear before, now you can understand why I'm = curious about the concrete details of this authentication service.) I think the general idea was a DKIM-like model, so if the =46rom field = value is 'bob@foo.com', then you check the cert it points you to is for = foo.com and signed by a CA you trust. That works for email-style names = like that, because you can verify it's coming from foo.com, and foo.com = is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust = are not compromised of course) The hard part comes with E.164 numbers, because even if they appear as = user@domain strings, like '+12125551212@foo.com', most SIP devices would = treat it as an E.164 number - and that means it's not scoped to foo.com = at all but rather a separate, global namespace that foo.com has no = natural authority for. So with 4474 you'd have to believe foo.com is = authoritative for the number based on reputation alone - i.e., you have = a local list of domains you trust to claim E.164 numbers. That would = work for a limited number of domain names, for example the domain names = of the major carriers within a country, but it would fall apart quickly = if we ever want Enterprises to sign, or international scenarios to work. So one proposal so far is that there would be certs which identify the = E.164 numbers they're authoritative for (in a CN/SAN field for example), = and that cert would be signed by some CA (or chain leading to one) that = you trust. If it's a chain rather than directly signed by a CA, then = it's not clear how one goes about retrieving the certs for the chain's = links, and doing so could cause unacceptable delay. It also means we = need revocation checks for the chain. And I'd argue the management = aspects for this thing would be just as difficult as anything else = proposed so far. -hadriel From md3135@att.com Sun Jun 16 10:47: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 0018C21F9CE8 for ; Sun, 16 Jun 2013 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, GB_AFFORDABLE=1, J_CHICKENPOX_21=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 Mo7LiMER1P82 for ; Sun, 16 Jun 2013 10:46:59 -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 2E14621F9CCA for ; Sun, 16 Jun 2013 10:46:59 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 31afdb15.2aaae562e940.122610.00-564.331858.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 16 Jun 2013 17:46:59 +0000 (UTC) X-MXL-Hash: 51bdfa13139edf3c-644487aa86fcf3e2e6164efa9aa560a2ddde3e4f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c0afdb15.0.122595.00-479.331820.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 16 Jun 2013 17:46:58 +0000 (UTC) X-MXL-Hash: 51bdfa1246446758-70a71bb09fe63b4bc8b4755d1dbaf3e90be80062 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 r5GHkpRU019614; Sun, 16 Jun 2013 13:46:52 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5GHkjaR019446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 13:46:48 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 16 Jun 2013 17:46:28 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 13:46:34 -0400 From: "DOLLY, MARTIN C" To: "dcrocker@bbiw.net" , "Peterson, Jon" Thread-Topic: [stir] current draft charter Thread-Index: AQHOaq/tPvBwdWSMpuU+7zbFbFufQ5k4j/9g Date: Sun, 16 Jun 2013 17:46:34 +0000 Message-ID: References: <51BDEA03.90808@dcrocker.net> In-Reply-To: <51BDEA03.90808@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.93.250] 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=Our4PVDt c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=BdHj8wnEcaQA:10 a=KIbchom90_cA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=UIkZVOpWgVUA:10 a=48vgC7mUAAAA:8 a=b8OvNEjoAAAA:8] X-AnalysisOut: [ a=k7Ga1wGzAAAA:8 a=MnlhHJT3Q70ji6rVdxQA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=x3I_HB9Tk8MA:10 a=lZB815dzVvQA:10 a=E1Snkw02GREA:10 a] X-AnalysisOut: [=4ztgWBe3F2clDeW5:21 a=Num8gS6gSzp_S7DL:21] Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 17:47:05 -0000 Hello all, Charter: 1. The issue/problem is "spoofing", and not routing nor media security. 2. And WRT spoofing, IP to IP spoofing solution is the low hanging fruit, a= nd we need to have a timely solution (timely includes standard, deployable,= including affordable)=20 3. validation is associated with authentication, which is best done by the = carrier or enterprise (though enterprises are a source of the robo-calls), = but should be allowed to be done by callee UAs (IF trusted, this is a big I= F) 4. ISUP cannot be modified, FULL STOP=20 5. Creatively using/reusing an existing ISUP parameter/field could only bet= ween trust domains. (WTS PAI works between trust domains) Regards, Martin -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dav= e Crocker Sent: Sunday, June 16, 2013 12:38 PM To: Peterson, Jon Cc: stir@ietf.org Subject: Re: [stir] current draft charter On 6/13/2013 6:58 PM, Peterson, Jon wrote: > On 6/13/13 3:24 PM, "Dave Crocker" wrote: >> On 6/13/2013 10:25 AM, Peterson, Jon wrote: >>> I just meant for example private DNS, or PKI, as it says up there. >> >> 1. The functional description that's been offered said that validation >> is to be permitted by entities such as callee-side enterprises and even >> callee UAs. That precludes any sort of private service. ... > Potentially, yes, callee-side enterprises and even callee UAs would be > able to validate. OK. Again: No "private" mechanisms. > The original RFC4474 model describes an abstract > "verification service" function that can be performed either by an > intermediary or an endpoint. I've been assuming we'd retain that > architecture. RFC 4474 has been standards track for 7 years; that's a long time. What is its level of operational deployment and use, so far? If the=20 answer is "not much", then it's not clear that automatically invoking=20 its application here is as comforting or facilitative as one might wish... The cornerstone of RFC 4474 is an (independent) authentication service.=20 Where are it's details specified? (Note that you correctly described=20 RFC 4474 as describing an abstract service; that begs the question of=20 the concrete details for its cornerstone. I'm also therefore assuming=20 that Section 5 of that document is not the concrete service protocol=20 details, since it's far from complete, in spite of having quite a bit of=20 detail. A telling example is the text in Step 2: "Some possible ways in=20 which this authentication might be performed include:") If I understand the RFC 4474 model correctly, a validated Identity field=20 has the semantics of asserting that the From field is valid. So the=20 assertion is not limited to the owner of the From field value. Correct?=20 While such a model is understandable, it dramatically increases the=20 reputation-management complexity of the task. I'm not aware of an=20 extant service over the public Internet of similar complexity. Better still is that it's the entity making the assertion that tells the=20 verifier where to look for verification information... What's seems to=20 be missing from the text in RFC 4474 is how the verifier can tell=20 whether the credential is a valid authorization for use of the From=20 field value. (If it wasn't clear before, now you can understand why I'm=20 curious about the concrete details of this authentication service.) > The RFC4474 model also has the concept that a URI is carried alongside th= e > signature, in a separate header called Identity-Info, to designate the > credential that was used to generate the signature. So yes, any > verification service needs to be able to resolve that URI, so it must be > public in at least that sense (and the verification service must trust > whatever trust anchor generated the credential on the other side of that "in that sense"? What other sense is possible and plausible? Perhaps I missed the details about the credential use that are specific=20 to this application. Where are they provided, so that it's possible to=20 tell how the credential is applicable for authorization validation? (Naive question: Are the details of the referenced URI use for=20 credential acquisition sufficient and well-deployed? It's a significant=20 protocol mechanism for this service and I'm not clear that it's the=20 mechanism or its semantics are standard practice.) > URI too). IF we were to transpose this to a DNS-like model, presumably th= e > Identity-Info header or its successor would be extended in some fashion t= o > allow it to designate that the DNS should be consulted. This being a global, public, integrated query service, and the track=20 record of deploying such things being highly discouraging, it's=20 definitely good to stay with a proven, deployed service. That's why I=20 asked after the experience with the independent authentication service=20 specified in RFC 4474. >> 2. From one of your earlier notes, I gather that by "PKI" you mean the >> bushy (multi-root) system that operates for SSL/TLS web services? You >> appear to be using PKI to mean a specific, integrated, operating >> credential service, so I would like to be clear about which specific one >> you mean; the one used by the Web seems to be it? > > I mean a system that resembles that "bushy" system, yes. I imagine it "Resembles" implies that it doesn't exist yet. So it's subject to=20 whatever challenges any other proposal must address. > could encompass multiple roots. The secure-origins-ps document does > however contain some text to the effect that it would be real nice if we > could avoid having different roots claiming authority over the same name, > though, given what the consequences of that have been for web PKI. That mostly says that the reality of this mechanism hasn't been=20 established yet. If it had, we'd know whether it had multiple roots and=20 whether that approach scaled well. The use of a multiple roots model for web validation is already showing=20 some signs of stress. >> By "query service" I meant the term generically as a mechanism that >> askes for something and gets it. I didn't want to imply or constrain any >> details about the form of the request or what was returned; merely that >> it's in the service of performing validation. > > Sure, as specified in RFC4474, https or even cid (to designate a multipar= t > MIME body attached to the request) are examples of how the credential > fetch would happen. It is definitely in the scope of proposed work to > expand those options. https is not a query service. In this context, it is at most a=20 transport service, that might have a query protocol running on top of it. >>>> It would help to also hear where such a design has already been >>>> successfully deployed. >>> >>> Do you think that is an issue for CAs/PKIs? Certainly they have some >>> rough >> >> The PKI service used for the web has the advantage of existing and being >> heavily used. A base of experience is goodness, when considering >> out-sourcing a component of a new service. Whether its characteristics >> suffice for the current project, I don't know. Some times, rough edges >> cut thing and bleed them dry. > > Like I said, I'd hope we could benefit from some of the operational > lessons of web PKI while still retaining the tried and true technologies > that have succeeded here. Operational lessons abound. Globally viable query services that are=20 applicable to real-time use do not. To date, the Web's PKI's has seen extremely narrow success. The biggest=20 lesson to take from a mechanism intended to be so flexible, after this=20 long, is that the continuing narrowness of current use should be a caution. >>> edges, which is why we see the DNS (through DANE) potentially playing a >> >> Ah yes, the great promise of DANE. I'm sure it will yet deliver, as >> have all of the other promising efforts in the IETF. Oh, no, this one >> really will. No, honest, it will. And I hope I'm serious. ... > But DANE wouldn't play a role in our story about how credentials are > managed for TNs unless of course we assume some ENUM-like TN hierarchy in > the DNS is a part of this key management solution. Ok. So it's /not/ "potentially playing a role" for this discussion. > Um. In so far as there is IETF work already formulated, as far as I know > it's what's captured in the various drafts under discussion. ... > Both have some dependency on credentials which capture authority over > telephone numbers. Unless I've missed something, this translates into creation of a new=20 global PKI service for authorizing third-party validation of number use.=20 (The third-party aspect refers to the use of the Identity field I=20 cited above.) That's pretty ambitious, especially in terms of OA&M, nevermind viable=20 trust/reputation. > The degree to which those credentials are a subject of > IETF work is less obvious to me. Let's assume we're talking about a PKI, > for the moment. In the web world, we have RFCs that talk about how you > need to process certs to make web security work, what information needs t= o > be in them and where it lives, and that is all clearly IETF work. But we > don't have RFCs that constrain the set of CAs to any particular vendor(s) > or that overly prescribe their operational environment, like how a CA > enrolls customers or sorts them into levels of assurance, say. Nevermind the IETF. Credentials are at the heart of your proposal for=20 this globally-integrated authorization service. So the details had=20 better be specified and reviewed somewhere. > So right now in the proposed charter there is a placeholder for a documen= t > that would cover the sorts of things about the key management system that > would be in the scope of the IETF, to foster interoperability of signers > and verifiers. "Foster" suggests that the service could be viable without that=20 interoperability being standardized? > I think we'd need to know more about where we're going > before I could tell you in more detail what the document would contain. S= o > yeah, a lot of things are not solid at this stage. > >> If there is in fact a concrete, detailed design already in hand, that >> attends to relevant security, privacy, scaling, deployment, >> administration and operations issues, let's hear it. > > For what part of the work? Any of it. As I said, I had been told private and rather forcefully that this=20 effort already had a solution in hand. I'm trying to re-gauge things, now that's it's clear that none of the=20 details are actually worked out yet. d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dcrocker@bbiw.net Sun Jun 16 10:52: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 8651D21F9B0C for ; Sun, 16 Jun 2013 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AN-uUbHCdhQi for ; Sun, 16 Jun 2013 10:52:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F13A21F9C25 for ; Sun, 16 Jun 2013 10:52:49 -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 r5GHqiY1017984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 10:52:48 -0700 Message-ID: <51BDFB60.6010402@bbiw.net> Date: Sun, 16 Jun 2013 10:52:32 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51BDEA03.90808@dcrocker.net> <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> In-Reply-To: <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Sun, 16 Jun 2013 10:52:48 -0700 (PDT) Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 17:52:54 -0000 On 6/16/2013 10:39 AM, Hadriel Kaplan wrote: > On Jun 16, 2013, at 12:38 PM, Dave Crocker > wrote: >> Better still is that it's the entity making the assertion that >> tells the verifier where to look for verification information... >> What's seems to be missing from the text in RFC 4474 is how the >> verifier can tell whether the credential is a valid authorization >> for use of the From field value. ... > I think the general idea was a DKIM-like model, so if the From field > value is 'bob@foo.com', then you check the cert it points you to is > for foo.com and signed by a CA you trust. That works for email-style We're in a space that requires quite a bit of care and precision, so forgive my pedantry when I note that DKIM does not have anything to do with the address in the rfc5322.From field, contrary to popular beliefs.[*] DKIM has its own identifier field (the d= parameter of the DKIM-Signature header field). It's entirely independent of all other identification information in the message. But note that DKIM semantics are completely different than what is proposed for STIR. The signer in DKIM merely asserts "some responsibility" for the message; this pointedly does /not/ include validating any of the message content, such as the From: address. The more recent DMARC, on the other hand, does assert "alignment" between the d= value and the From: field domain. However DMARC is intended for narrow use. In particular, it does not work for messages that get re-posted, such as mailing lists. I think that such cases match concerns for SIP/PSTN gateways. > So one proposal so far is that there would be certs which identify > the E.164 numbers they're authoritative for (in a CN/SAN field for > example), and that cert would be signed by some CA (or chain leading > to one) that you trust. If it's a chain rather than directly signed > by a CA, then it's not clear how one goes about retrieving the certs > for the chain's links, and doing so could cause unacceptable delay. > It also means we need revocation checks for the chain. And I'd argue > the management aspects for this thing would be just as difficult as > anything else proposed so far. Ack. FWIW, I've always viewed the administrative requirements for DKIM far, far more challenging than the signing/verifying mechanisms. After some years of extensive deployment experience with DKIM, my opinion has not changed... d/ [*] The DKIM signing hash does include the From field, but that's different from using the value semantically. -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Sun Jun 16 10:53: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 83BD821F9C25 for ; Sun, 16 Jun 2013 10:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 YK-r05QhRsDw for ; Sun, 16 Jun 2013 10:53:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E794E21F9B12 for ; Sun, 16 Jun 2013 10:53:20 -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 r5GHrH4Q017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 10:53:20 -0700 Message-ID: <51BDFB81.5030502@dcrocker.net> Date: Sun, 16 Jun 2013 10:53:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51BDEA03.90808@dcrocker.net> <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> In-Reply-To: <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 16 Jun 2013 10:53:20 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 17:53:25 -0000 On 6/16/2013 10:39 AM, Hadriel Kaplan wrote: > On Jun 16, 2013, at 12:38 PM, Dave Crocker > wrote: >> Better still is that it's the entity making the assertion that >> tells the verifier where to look for verification information... >> What's seems to be missing from the text in RFC 4474 is how the >> verifier can tell whether the credential is a valid authorization >> for use of the From field value. ... > I think the general idea was a DKIM-like model, so if the From field > value is 'bob@foo.com', then you check the cert it points you to is > for foo.com and signed by a CA you trust. That works for email-style We're in a space that requires quite a bit of care and precision, so forgive my pedantry when I note that DKIM does not have anything to do with the address in the rfc5322.From field, contrary to popular beliefs.[*] DKIM has its own identifier field (the d= parameter of the DKIM-Signature header field). It's entirely independent of all other identification information in the message. But note that DKIM semantics are completely different than what is proposed for STIR. The signer in DKIM merely asserts "some responsibility" for the message; this pointedly does /not/ include validating any of the message content, such as the From: address. The more recent DMARC, on the other hand, does assert "alignment" between the d= value and the From: field domain. However DMARC is intended for narrow use. In particular, it does not work for messages that get re-posted, such as mailing lists. I think that such cases match concerns for SIP/PSTN gateways. > So one proposal so far is that there would be certs which identify > the E.164 numbers they're authoritative for (in a CN/SAN field for > example), and that cert would be signed by some CA (or chain leading > to one) that you trust. If it's a chain rather than directly signed > by a CA, then it's not clear how one goes about retrieving the certs > for the chain's links, and doing so could cause unacceptable delay. > It also means we need revocation checks for the chain. And I'd argue > the management aspects for this thing would be just as difficult as > anything else proposed so far. Ack. FWIW, I've always viewed the administrative requirements for DKIM far, far more challenging than the signing/verifying mechanisms. After some years of extensive deployment experience with DKIM, my opinion has not changed... d/ [*] The DKIM signing hash does include the From field, but that's different from using the value semantically. -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From hgs@cs.columbia.edu Sun Jun 16 14:39: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 5869721F9D2E for ; Sun, 16 Jun 2013 14:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 TdAPaNxQOYwP for ; Sun, 16 Jun 2013 14:39:22 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id D166921F9C7A for ; Sun, 16 Jun 2013 14:39:17 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5GLdEqm029960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Jun 2013 17:39:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com> Date: Sun, 16 Jun 2013 17:39:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C2FC962-375E-4886-A15A-100E0031FE2D@cs.columbia.edu> References: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 16 Jun 2013 21:39:28 -0000 On Jun 15, 2013, at 3:06 PM, Hadriel Kaplan wrote: >=20 > On Jun 13, 2013, at 9:12 PM, Henning Schulzrinne = wrote: >=20 >> Also, I suspect there would be fewer concerns if the DNS-like = database mainly referred to other databases, which can then be = access-controlled as needed, and can evolve. >=20 > But that's just moving the problem around, isn't it? Yes, in the spirit of "All problems in computer science can be solved by = another level of indirection". My hunch is that = directories/databases/DNS that try to enforce policy are likely to fail, = but relatively policy-neutral ones have a better chance. >=20 > I mean ultimately some of us might want to actually implement the = signing and verification into our systems. If it uses public-key = signatures, then we need a standardized protocol by which our systems = can query for a certificate signed by some authority we trust for a = given E.164 number. If DNS tells us "go look over at FOO": then what = standardized protocol does FOO use that we need to implement? Wouldn't plain HTTPS do the trick, as in 4474? > why should we trust it for this caller-id? and how does it avoid the = privacy problems and ownership problems and so on? How do you even know = we can reach FOO, if it's not necessarily publicly reachable? >=20 > I mean all I've heard is this:=20 > Step-1) Some magic happens somewhere, to enable the caller to generate = a HTTP URL anyone can use** > Step-2) You get the HTTP URL in SIP from the caller through some chain = of providers > Step-3) You send a GET request to above URL > Step-4) Some more magic happens** > Step-5) You get back a magic certificate > Step-6) You trust the magic was real, and use the cert to verify > Step-7) Ta-da! You've now verified the caller-id! > Step-8) Profit. >=20 > **note: please contact the universal magician so we can make the magic = stuff happen for you and everyone else. I don't think it's quite *that* bad. What I've heard so far is some = version of: * Very small number of entities (1-10ish per country code) sign "public = key X is entitled to use TN [range] A". The cert is conveyed in some = proprietary fashion to the number holder, similar to how today's web = CA's deliver certs to their customers. A single entity can have any = number of public keys, if they want to obscure their number holdings or = for operational reasons. Working group to-do: Define appropriate X.509 = content for numbers. * Small number of "convenience" database providers host certs, including = possibly carriers (if they don't care about identifying themselves). The = database providers offer scaling and access control. National policy = decides what kind of access needs to be granted to whom (fees, = non-discrimination, etc.). * Certs are retrieved via the HTTPS URL that's included in 4474bis = header. Clearly, the entity doing the signing has to know where to find = the cert, but as long as the number of entities signing is small, this = seems quite manageable. * The validator knows trusted root CAs. Future work: A DANE-like = mechanism to list those, e.g., based on prefixes (e.g., +1 might list = the number administrator(s) in the US and other +1 countries). As long = as the number of CAs for each country code prefix is very small (which = seems likely, at least initially), there's no great need to have = references for each TN, while still preventing the Nigerian NRA signing = +1 numbers. It might be interesting to see how much of EPP is applicable here. As far as I can tell, assuming 4474bis header mods and the X.509 = customs, you could build a system that allows interoperable validation. = The only proprietary piece, initially, would be the cert delivery to the = number holder. Is that a bit less magic? >=20 >> Also, keeping scale in mind helps: In our case, the scale for = "number-holding service providers" is currently a few thousand, not = millions, so management solutions that don't scale to millions are = acceptable to get started. The backend process today is pretty manual = (faxes, web pages and proprietary APIs), so expectations are fairly low. >=20 > See, that matches up well with DNS too! The backend management/admin = process is pretty manual afaict. ;) >=20 > -hadriel >=20 >=20 From hgs@cs.columbia.edu Sun Jun 16 14:54: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 8807421F9D27 for ; Sun, 16 Jun 2013 14:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 UKfRhfPtKpk2 for ; Sun, 16 Jun 2013 14:54:33 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 832DE21F9D1C for ; Sun, 16 Jun 2013 14:54:32 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5GLsUCZ002726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Jun 2013 17:54:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Sun, 16 Jun 2013 17:54:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: stir@ietf.org Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 21:54:37 -0000 While you can spoof the caller ID, you (generally) cannot spoof the = calls that reach you, unless you can get the real number holder to = redirect calls to you. According to a brief discussion at the FTC robocalling workshop = [http://www.ftc.gov/bcp/workshops/robocalls/], the latter is actually = not too far-fetched, particularly since many such redirection settings = are now just web configurations or are done via apps on a cell phone. = Thus, you don't have to compromise the carrier infrastructure to = redirect calls, just an end user. Probably not a major threat yet for a = call center or large-business number at the moment, but possibly for an = individual or small business. > With regard to ViPR, I was under the impression ViPR's entire = foundation for trust authority rested on the PSTN, with the original = PSTN call and its caller-ids being part of the shared secret for later = use in ViPR peer discovery and authentication. If the caller-id's in = the PSTN can be faked, ViPR would have been in very big trouble, because = it would have enabled incorrectly finding and authenticating a malicious = peer for that spoofed number and making all future calls back to that = malicious peer for the number. No? (maybe ViPR changed after I stopped = following it) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From jon.peterson@neustar.biz Sun Jun 16 15:32: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 9A39721F9AD2 for ; Sun, 16 Jun 2013 15:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fD7Kvy9Vexyg for ; Sun, 16 Jun 2013 15:32:12 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 73BE721F9425 for ; Sun, 16 Jun 2013 15:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371421874; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=9V6yEWvEFb V7aOvwwgF/j9vi1ArvjIw2fSYUBKPa7Ek=; b=c1wlEhVTzHSz0JRIjJj8aVZRwU OPG4RLcUZ8AU3vrFS9CYy8eFBkpxkYBnP6h5/+cX37MCorDE/aymX+DcqPfw== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21037652; Sun, 16 Jun 2013 18:31:13 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 18:31:59 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAIAABbCAgAANuID//5nhgACbcLuAACsi9IA= Date: Sun, 16 Jun 2013 22:31:58 +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.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: dyyp4h15C7EmbiZBGGgFug== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Dave Crocker , Brian Rosen Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 22:32:16 -0000 No, I didn't mean return routability as a real-time check during call processing a la Jabber, I meant some system of proving possession of a number as a means of enrolling into the PKI (or whatever other key management system there may be). ViPR's technique is one example; other examples would be things like sending an SMS to a smartphone with a link you could click to prove possession. In the email world, you might compare this to S/MIME credentials you receive in return for proving you control an email address. I don't think we need to prescribe what the possible set of enrollment mechanisms are here, just to say that there exist alternative ways to enroll other than top-down delegation. And I don't mean to suggest that credentials secured for this purpose would only be useful in the out-of-band solution, either. Just to second Henning here, faking the calling party number is a very different matter than forcing calls for a number to be routed to a different endpoint. Subverting VIPR required doing the latter, not the former. This is the difference between arbitrarily populating the From header field of SIP with "sip:jon@example.com" to pretend to be me, and then then making it so when someone else sends a request to sip:jon@example.com it ends up ringing your phone. One is trivial, the other not so much. Now that much said, there were lots of lingering question in VIPR about what happens when you're not directly connected to the PSTN, due to SIP trunking or what have you, and how VIPR endpoints can be assured that PSTN routing was actually invoked. This is something we'll need to be mindful of. Jon Peterson Neustar, Inc. On 6/15/13 11:56 AM, "Hadriel Kaplan" wrote: > >On Jun 12, 2013, at 7:46 PM, "Peterson, Jon" >wrote: > >> The proposed STIR charter outlines two ways to secure identity: an >>in-band >> and an out-of-band approach. Discussion so far on this list has focused >> largely on the in-band. For the out-of-band approach, we need to be able >> to explore credentials whose authority rests on some other means than >> delegation from on high: perhaps, like in ViPR, from probing how numbers >> are routed and using this to prove possession of the number. > >If you mean check return routability, Dan Wing had a draft on a >return-routability check: >http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01 > >Unfortunately, legitimate caller-ids are sourced by elements/entities >that are not necessarily the same ones used for reaching the same number >back. For example the call-center scenarios, or doctor cellphone >scenario, or even Skype-out scenario. > >With regard to ViPR, I was under the impression ViPR's entire foundation >for trust authority rested on the PSTN, with the original PSTN call and >its caller-ids being part of the shared secret for later use in ViPR peer >discovery and authentication. If the caller-id's in the PSTN can be >faked, ViPR would have been in very big trouble, because it would have >enabled incorrectly finding and authenticating a malicious peer for that >spoofed number and making all future calls back to that malicious peer >for the number. No? (maybe ViPR changed after I stopped following it) > >-hadriel > From jon.peterson@neustar.biz Sun Jun 16 16:28: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 B580A21F9D41 for ; Sun, 16 Jun 2013 16:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 ZMIfBAZVRHeL for ; Sun, 16 Jun 2013 16:28:05 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 818C921F9D4B for ; Sun, 16 Jun 2013 16:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371425175; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=LHbvTS6EYF P1e93R/0RxYv6Yj8hksCgBFQfW5ign3rM=; b=APFrc5VoXnMEvAuCdZDsp4HD+3 SlO58DVj7+tsNFm321wm4J6mSwgISGD+d6gSCWScufCKcTXT9rQHRcSoQCtQ== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19600652; Sun, 16 Jun 2013 19:26:13 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 19:27:55 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgA= Date: Sun, 16 Jun 2013 23:27:55 +0000 Message-ID: In-Reply-To: <259384BE-383F-4D1A-81F1-6F7853B7FE61@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uS2uB5qOWSLIeEHVtvuqxQ== Content-Type: text/plain; charset="Windows-1252" Content-ID: <82977A88504F4E46BCB78DFDEA7AFA2B@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 23:28:09 -0000 > >> RFC 4474 has been standards track for 7 years; that's a long time. >>=20 >> What is its level of operational deployment and use, so far? If the >>answer is "not much", then it's not clear that automatically invoking >>its application here is as comforting or facilitative as one might wish= =8A > >The answer is less than "not much"... more like "not at all". >I'd argue the reasons it has never been deployed are: (1) people didn't >believe there was an identity spoofing problem yet, (2) it only really >validates email-style identities such as alice@foo.com, not E.164 >numbers, and (3) it's not deployable due to B2BUAs changing the fields it >would sign. I agree with those three reasons. I'd further say (1) is part of a broader trend in which the deployment community hasn't shown much interest in the security mechanisms available in SIP versus operating in effectively private environments. These identity spoofing concerns show a limitation of transitive trust in these private communities. >> If I understand the RFC 4474 model correctly, a validated Identity >>field has the semantics of asserting that the From field is valid. So >>the assertion is not limited to the owner of the From field value. >>Correct? While such a model is understandable, it dramatically >>increases the reputation-management complexity of the task. I'm not >>aware of an extant service over the public Internet of similar >>complexity. We weren't exactly proposing a domain assurance council or something like that. The authorization decision was supposed to be checking the reference integrity of the domain in the From header field against the domain in the subjectAltName of the cert (provided the cert is valid and the root trusted): if there's a match, then this was signed for by the right entity, if not, then not. I'm not sure what you mean by "not limited to the owner of the From field value." In so far as the originating domain is the "owner," then only they can sign it, if that's the limitation you're concerned about. >>=20 >> Better still is that it's the entity making the assertion that tells >>the verifier where to look for verification information... What's seems >>to be missing from the text in RFC 4474 is how the verifier can tell >>whether the credential is a valid authorization for use of the From >>field value. (If it wasn't clear before, now you can understand why I'm >>curious about the concrete details of this authentication service.) >I think the general idea was a DKIM-like model, so if the From field >value is 'bob@foo.com', then you check the cert it points you to is for >foo.com and signed by a CA you trust. That works for email-style names >like that, because you can verify it's coming from foo.com, and foo.com >is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust >are not compromised of course) Correct. The entity making the assertion tells the verifier where a cert can be fetched, in the case that the verifier doesn't already have a cert for the signer. Whether the cert is valid, or the CA itself is trusted by the verifier, is however a different and prior question. >The hard part comes with E.164 numbers, because even if they appear as >user@domain strings, like '+12125551212@foo.com', most SIP devices would >treat it as an E.164 number - and that means it's not scoped to foo.com >at all but rather a separate, global namespace that foo.com has no >natural authority for. So with 4474 you'd have to believe foo.com is >authoritative for the number based on reputation alone - i.e., you have a >local list of domains you trust to claim E.164 numbers. That would work >for a limited number of domain names, for example the domain names of the >major carriers within a country, but it would fall apart quickly if we >ever want Enterprises to sign, or international scenarios to work. Right. At the risk of waxing philosophical about it, I'd say that RFC4474 took for granted the baseline assumption that RFC3263 would be how SIP requests were routed. If you assume SIP requests get routed by taking the domain portion of the request-URI and looking it up in the DNS to locate a SIP server, RFC4474 probably isn't a bad fit for what you do. If however SIP requests get routed based on the user portion of the Request-URI (like a TN) without reference to the DNS, then probably having a domain sign for identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty much all about that. >So one proposal so far is that there would be certs which identify the >E.164 numbers they're authoritative for (in a CN/SAN field for example), >and that cert would be signed by some CA (or chain leading to one) that >you trust. If it's a chain rather than directly signed by a CA, then >it's not clear how one goes about retrieving the certs for the chain's >links, and doing so could cause unacceptable delay. It also means we >need revocation checks for the chain. And I'd argue the management >aspects for this thing would be just as difficult as anything else >proposed so far. Although I'm not the expert, my understanding is that there are various cert chain compression techniques that could be applicable here. I've squinted a bit at OCSP and other possible real-time revocation checks for this as well. The exact amount of tolerable delay is a very interesting dimension of this problem space. I suspect we have a considerable amount of time, given all the human expectations about both post-dial delay and the wait for someone to pick up after altering. I think it's enough time to perform some non-trivial operations. But I do agree that there's no such thing as a free lunch, and that implementing a credential system for telephone numbers, even just in a single nation state, is operationally complex. In my day job, we have a few different credentials today that carriers can use to interface with various NANPA/NPAC system, and some of them already have requirements similar to what we've discussed here, like delegation for example. I think if we go down this STIR path, at the end of the day we'll end up with a system that relies on many numbers aggregated behind a single credential, on signatures and validations being performed by network elements much more so than endpoints, and similar optimizations. Provided we can do this without making e2e security impracticable, I think we'll be on the right track. Jon Peterson Neustar, Inc. >-hadriel > From md3135@att.com Sun Jun 16 16:45: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 02D7521F9CFF for ; Sun, 16 Jun 2013 16:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 2UDvdkImYZi3 for ; Sun, 16 Jun 2013 16:45:44 -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 27B7421F9C7A for ; Sun, 16 Jun 2013 16:45:44 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 82e4eb15.2aab02c5d940.192372.00-568.522089.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 16 Jun 2013 23:45:44 +0000 (UTC) X-MXL-Hash: 51be4e287efcb1f7-586657dfc4d944c504258b4da490930a8282484f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 32e4eb15.0.192353.00-475.522036.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 16 Jun 2013 23:45:43 +0000 (UTC) X-MXL-Hash: 51be4e271c32cdf1-9f07c402d79b06f8dabcd829fdb65c4d7f1c645f 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 r5GNjdSk026112; Sun, 16 Jun 2013 19:45:39 -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 r5GNjXX7026071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 19:45:36 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 16 Jun 2013 23:45:24 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 19:45:30 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" , Hadriel Kaplan , "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOaq/tPvBwdWSMpuU+7zbFbFufQ5k43nSAgABhe4D//8BOQA== Date: Sun, 16 Jun 2013 23:45:29 +0000 Message-ID: References: <259384BE-383F-4D1A-81F1-6F7853B7FE61@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.175.93.250] Content-Type: text/plain; charset="iso-8859-2" 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=Our4PVDt c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=BdHj8wnEcaQA:10 a=KIbchom90_cA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=-CRmgG0JhlAA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=UIkZVOpWgVUA:10 a=48vgC7mUAAAA:8 a=k7Ga1wGzAAAA:8] X-AnalysisOut: [ a=P5wrnlEIAAAA:8 a=BDZlRqII8_rn4MoU2YkA:9 a=jiObf9B0YAUA:] X-AnalysisOut: [10 a=ZEB4BVPQL1cA:10 a=K6OZBpTtl3cA:10 a=lZB815dzVvQA:10 a] X-AnalysisOut: [=fcAx7uNQz4EA:10 a=nXjPMxIiGpsA:10 a=kLbOSHPRN9KYCEIV:21 a] X-AnalysisOut: [=mnKUKrXmXs5M1ncA:21] Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Sun, 16 Jun 2013 23:45:58 -0000 John, You said,=20 I agree with those three reasons. I'd further say (1) is part of a broader trend in which the deployment community hasn't shown much interest in the security mechanisms available in SIP versus operating in effectively private environments. These identity spoofing concerns show a limitation of transitive trust in these private communities. [mcd] - the issue is not between trusted carriers, but rather traffic of th= e wholesale/enterprise. {mcd} - further the charter needs to focus on the violating parties. Regards, Martin -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pet= erson, Jon Sent: Sunday, June 16, 2013 7:28 PM To: Hadriel Kaplan; dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] current draft charter > >> RFC 4474 has been standards track for 7 years; that's a long time. >>=20 >> What is its level of operational deployment and use, so far? If the >>answer is "not much", then it's not clear that automatically invoking >>its application here is as comforting or facilitative as one might wish= =A9 > >The answer is less than "not much"... more like "not at all". >I'd argue the reasons it has never been deployed are: (1) people didn't >believe there was an identity spoofing problem yet, (2) it only really >validates email-style identities such as alice@foo.com, not E.164 >numbers, and (3) it's not deployable due to B2BUAs changing the fields it >would sign. I agree with those three reasons. I'd further say (1) is part of a broader trend in which the deployment community hasn't shown much interest in the security mechanisms available in SIP versus operating in effectively private environments. These identity spoofing concerns show a limitation of transitive trust in these private communities. >> If I understand the RFC 4474 model correctly, a validated Identity >>field has the semantics of asserting that the From field is valid. So >>the assertion is not limited to the owner of the From field value. >>Correct? While such a model is understandable, it dramatically >>increases the reputation-management complexity of the task. I'm not >>aware of an extant service over the public Internet of similar >>complexity. We weren't exactly proposing a domain assurance council or something like that. The authorization decision was supposed to be checking the reference integrity of the domain in the From header field against the domain in the subjectAltName of the cert (provided the cert is valid and the root trusted): if there's a match, then this was signed for by the right entity, if not, then not. I'm not sure what you mean by "not limited to the owner of the From field value." In so far as the originating domain is the "owner," then only they can sign it, if that's the limitation you're concerned about. >>=20 >> Better still is that it's the entity making the assertion that tells >>the verifier where to look for verification information... What's seems >>to be missing from the text in RFC 4474 is how the verifier can tell >>whether the credential is a valid authorization for use of the From >>field value. (If it wasn't clear before, now you can understand why I'm >>curious about the concrete details of this authentication service.) >I think the general idea was a DKIM-like model, so if the From field >value is 'bob@foo.com', then you check the cert it points you to is for >foo.com and signed by a CA you trust. That works for email-style names >like that, because you can verify it's coming from foo.com, and foo.com >is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust >are not compromised of course) Correct. The entity making the assertion tells the verifier where a cert can be fetched, in the case that the verifier doesn't already have a cert for the signer. Whether the cert is valid, or the CA itself is trusted by the verifier, is however a different and prior question. >The hard part comes with E.164 numbers, because even if they appear as >user@domain strings, like '+12125551212@foo.com', most SIP devices would >treat it as an E.164 number - and that means it's not scoped to foo.com >at all but rather a separate, global namespace that foo.com has no >natural authority for. So with 4474 you'd have to believe foo.com is >authoritative for the number based on reputation alone - i.e., you have a >local list of domains you trust to claim E.164 numbers. That would work >for a limited number of domain names, for example the domain names of the >major carriers within a country, but it would fall apart quickly if we >ever want Enterprises to sign, or international scenarios to work. Right. At the risk of waxing philosophical about it, I'd say that RFC4474 took for granted the baseline assumption that RFC3263 would be how SIP requests were routed. If you assume SIP requests get routed by taking the domain portion of the request-URI and looking it up in the DNS to locate a SIP server, RFC4474 probably isn't a bad fit for what you do. If however SIP requests get routed based on the user portion of the Request-URI (like a TN) without reference to the DNS, then probably having a domain sign for identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty much all about that. >So one proposal so far is that there would be certs which identify the >E.164 numbers they're authoritative for (in a CN/SAN field for example), >and that cert would be signed by some CA (or chain leading to one) that >you trust. If it's a chain rather than directly signed by a CA, then >it's not clear how one goes about retrieving the certs for the chain's >links, and doing so could cause unacceptable delay. It also means we >need revocation checks for the chain. And I'd argue the management >aspects for this thing would be just as difficult as anything else >proposed so far. Although I'm not the expert, my understanding is that there are various cert chain compression techniques that could be applicable here. I've squinted a bit at OCSP and other possible real-time revocation checks for this as well. The exact amount of tolerable delay is a very interesting dimension of this problem space. I suspect we have a considerable amount of time, given all the human expectations about both post-dial delay and the wait for someone to pick up after altering. I think it's enough time to perform some non-trivial operations. But I do agree that there's no such thing as a free lunch, and that implementing a credential system for telephone numbers, even just in a single nation state, is operationally complex. In my day job, we have a few different credentials today that carriers can use to interface with various NANPA/NPAC system, and some of them already have requirements similar to what we've discussed here, like delegation for example. I think if we go down this STIR path, at the end of the day we'll end up with a system that relies on many numbers aggregated behind a single credential, on signatures and validations being performed by network elements much more so than endpoints, and similar optimizations. Provided we can do this without making e2e security impracticable, I think we'll be on the right track. Jon Peterson Neustar, Inc. >-hadriel > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Sun Jun 16 17:22: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 DDD4C21F9DBE for ; Sun, 16 Jun 2013 17:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 hvYXD3+IM1GJ for ; Sun, 16 Jun 2013 17:22:13 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEF821F9DBB for ; Sun, 16 Jun 2013 17:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371428468; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=/xroY7PPyY c3WsDOoF9xRCTAaJgeeX0aZQdjudJeczk=; b=tJY0bumcUNHidd7CJGHrvMckqX WIYvj+0jT2U4Z1+iW9nI6vnrbZyq4ZzJqG5EvSpUZ7Ndrl8XDQq80H7KymqA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21039208; Sun, 16 Jun 2013 20:21:07 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 20:21:54 -0400 From: "Peterson, Jon" To: "DOLLY, MARTIN C" , Hadriel Kaplan , "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAHo9gP//lNGA Date: Mon, 17 Jun 2013 00:21:53 +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.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: E8rkqoHAb+dvhGo+U+Lcow== Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 17 Jun 2013 00:22:17 -0000 >[mcd] - the issue is not between trusted carriers, but rather traffic of >the wholesale/enterprise. I'm sure you're right, but from a technology perspective it's the protocol-level trust itself that we can improve here. >{mcd} - further the charter needs to focus on the violating parties. Again, I think the IETF can only focusing on designing technology that doesn't suffer from these problems. Violating parties will not exactly be early adopters of protocols that constrain them, so we can't expect to charter work that they will abide by. What we can do is try to make the identity story better all around, so that violating parties are marginalized. But if there's something specific in the charter text you'd want to see different to capture this, let me know. Jon Peterson Neustar, Inc. > >Regards, > >Martin > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Peterson, Jon >Sent: Sunday, June 16, 2013 7:28 PM >To: Hadriel Kaplan; dcrocker@bbiw.net >Cc: stir@ietf.org >Subject: Re: [stir] current draft charter > > >> >>> RFC 4474 has been standards track for 7 years; that's a long time. >>>=20 >>> What is its level of operational deployment and use, so far? If the >>>answer is "not much", then it's not clear that automatically invoking >>>its application here is as comforting or facilitative as one might wish= =A9 >> >>The answer is less than "not much"... more like "not at all". >>I'd argue the reasons it has never been deployed are: (1) people didn't >>believe there was an identity spoofing problem yet, (2) it only really >>validates email-style identities such as alice@foo.com, not E.164 >>numbers, and (3) it's not deployable due to B2BUAs changing the fields it >>would sign. > >I agree with those three reasons. I'd further say (1) is part of a broader >trend in which the deployment community hasn't shown much interest in the >security mechanisms available in SIP versus operating in effectively >private environments. These identity spoofing concerns show a limitation >of transitive trust in these private communities. > >>> If I understand the RFC 4474 model correctly, a validated Identity >>>field has the semantics of asserting that the From field is valid. So >>>the assertion is not limited to the owner of the From field value. >>>Correct? While such a model is understandable, it dramatically >>>increases the reputation-management complexity of the task. I'm not >>>aware of an extant service over the public Internet of similar >>>complexity. > >We weren't exactly proposing a domain assurance council or something like >that. The authorization decision was supposed to be checking the reference >integrity of the domain in the From header field against the domain in the >subjectAltName of the cert (provided the cert is valid and the root >trusted): if there's a match, then this was signed for by the right >entity, if not, then not. I'm not sure what you mean by "not limited to >the owner of the From field value." In so far as the originating domain is >the "owner," then only they can sign it, if that's the limitation you're >concerned about. > >>>=20 >>> Better still is that it's the entity making the assertion that tells >>>the verifier where to look for verification information... What's seems >>>to be missing from the text in RFC 4474 is how the verifier can tell >>>whether the credential is a valid authorization for use of the From >>>field value. (If it wasn't clear before, now you can understand why I'm >>>curious about the concrete details of this authentication service.) >>I think the general idea was a DKIM-like model, so if the From field >>value is 'bob@foo.com', then you check the cert it points you to is for >>foo.com and signed by a CA you trust. That works for email-style names >>like that, because you can verify it's coming from foo.com, and foo.com >>is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust >>are not compromised of course) > >Correct. The entity making the assertion tells the verifier where a cert >can be fetched, in the case that the verifier doesn't already have a cert >for the signer. Whether the cert is valid, or the CA itself is trusted by >the verifier, is however a different and prior question. > >>The hard part comes with E.164 numbers, because even if they appear as >>user@domain strings, like '+12125551212@foo.com', most SIP devices would >>treat it as an E.164 number - and that means it's not scoped to foo.com >>at all but rather a separate, global namespace that foo.com has no >>natural authority for. So with 4474 you'd have to believe foo.com is >>authoritative for the number based on reputation alone - i.e., you have a >>local list of domains you trust to claim E.164 numbers. That would work >>for a limited number of domain names, for example the domain names of the >>major carriers within a country, but it would fall apart quickly if we >>ever want Enterprises to sign, or international scenarios to work. > >Right. At the risk of waxing philosophical about it, I'd say that RFC4474 >took for granted the baseline assumption that RFC3263 would be how SIP >requests were routed. If you assume SIP requests get routed by taking the >domain portion of the request-URI and looking it up in the DNS to locate a >SIP server, RFC4474 probably isn't a bad fit for what you do. If however >SIP requests get routed based on the user portion of the Request-URI (like >a TN) without reference to the DNS, then probably having a domain sign for >identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty >much all about that. > >>So one proposal so far is that there would be certs which identify the >>E.164 numbers they're authoritative for (in a CN/SAN field for example), >>and that cert would be signed by some CA (or chain leading to one) that >>you trust. If it's a chain rather than directly signed by a CA, then >>it's not clear how one goes about retrieving the certs for the chain's >>links, and doing so could cause unacceptable delay. It also means we >>need revocation checks for the chain. And I'd argue the management >>aspects for this thing would be just as difficult as anything else >>proposed so far. > >Although I'm not the expert, my understanding is that there are various >cert chain compression techniques that could be applicable here. I've >squinted a bit at OCSP and other possible real-time revocation checks for >this as well. > >The exact amount of tolerable delay is a very interesting dimension of >this problem space. I suspect we have a considerable amount of time, given >all the human expectations about both post-dial delay and the wait for >someone to pick up after altering. I think it's enough time to perform >some non-trivial operations. > >But I do agree that there's no such thing as a free lunch, and that >implementing a credential system for telephone numbers, even just in a >single nation state, is operationally complex. In my day job, we have a >few different credentials today that carriers can use to interface with >various NANPA/NPAC system, and some of them already have requirements >similar to what we've discussed here, like delegation for example. I think >if we go down this STIR path, at the end of the day we'll end up with a >system that relies on many numbers aggregated behind a single credential, >on signatures and validations being performed by network elements much >more so than endpoints, and similar optimizations. Provided we can do this >without making e2e security impracticable, I think we'll be on the right >track. > >Jon Peterson >Neustar, Inc. > >>-hadriel >> > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Sun Jun 16 17:31: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 AAEC321F9DCE for ; Sun, 16 Jun 2013 17:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 bEGeWzjV1LAS for ; Sun, 16 Jun 2013 17:31:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5543721F9DCA for ; Sun, 16 Jun 2013 17:31:28 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 0e85eb15.62a21940.188076.00-551.510128.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 17 Jun 2013 00:31:28 +0000 (UTC) X-MXL-Hash: 51be58e04c335d45-6ba4782684d603750a4fbfe02f60736565029a47 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id bd85eb15.0.188062.00-472.510076.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 17 Jun 2013 00:31:27 +0000 (UTC) X-MXL-Hash: 51be58df14518644-534a8ac012feed40a2eaa81c0348335289b103ca 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 r5H0VNiK011524; Sun, 16 Jun 2013 20:31:23 -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 r5H0VDvm011451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 20:31:18 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 17 Jun 2013 00:31:01 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 20:31:08 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" , Hadriel Kaplan , "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOaq/tPvBwdWSMpuU+7zbFbFufQ5k43nSAgABhe4D//8BOQIAATsaA//+++3A= Date: Mon, 17 Jun 2013 00:31:07 +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.93.250] Content-Type: text/plain; charset="iso-8859-2" 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=Geiga3rL c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=BdHj8wnEcaQA:10 a=KIbchom90_cA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=-CRmgG0JhlAA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=UIkZVOpWgVUA:10 a=hGBaWAWWAAAA:8 a=k7Ga1wGzAAAA:8] X-AnalysisOut: [ a=48vgC7mUAAAA:8 a=P5wrnlEIAAAA:8 a=XhPe_T0AduQkn-Z1ZD4A:] X-AnalysisOut: [9 a=jiObf9B0YAUA:10 a=ZEB4BVPQL1cA:10 a=K6OZBpTtl3cA:10 a=] X-AnalysisOut: [fcAx7uNQz4EA:10 a=lZB815dzVvQA:10 a=nXjPMxIiGpsA:10 a=E4zm] X-AnalysisOut: [qQJlaqnQWI_r:21 a=mlKXuA2ozBsubjRA:21] Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 17 Jun 2013 00:31:35 -0000 So, we define a charter to a solution that we want to get at, versus in REA= LLITY need to solve... I am simple, so please explain... -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: Sunday, June 16, 2013 8:22 PM To: DOLLY, MARTIN C; Hadriel Kaplan; dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] current draft charter >[mcd] - the issue is not between trusted carriers, but rather traffic of >the wholesale/enterprise. I'm sure you're right, but from a technology perspective it's the protocol-level trust itself that we can improve here. >{mcd} - further the charter needs to focus on the violating parties. Again, I think the IETF can only focusing on designing technology that doesn't suffer from these problems. Violating parties will not exactly be early adopters of protocols that constrain them, so we can't expect to charter work that they will abide by. What we can do is try to make the identity story better all around, so that violating parties are marginalized. But if there's something specific in the charter text you'd want to see different to capture this, let me know. Jon Peterson Neustar, Inc. > >Regards, > >Martin > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Peterson, Jon >Sent: Sunday, June 16, 2013 7:28 PM >To: Hadriel Kaplan; dcrocker@bbiw.net >Cc: stir@ietf.org >Subject: Re: [stir] current draft charter > > >> >>> RFC 4474 has been standards track for 7 years; that's a long time. >>>=20 >>> What is its level of operational deployment and use, so far? If the >>>answer is "not much", then it's not clear that automatically invoking >>>its application here is as comforting or facilitative as one might wish= =A9 >> >>The answer is less than "not much"... more like "not at all". >>I'd argue the reasons it has never been deployed are: (1) people didn't >>believe there was an identity spoofing problem yet, (2) it only really >>validates email-style identities such as alice@foo.com, not E.164 >>numbers, and (3) it's not deployable due to B2BUAs changing the fields it >>would sign. > >I agree with those three reasons. I'd further say (1) is part of a broader >trend in which the deployment community hasn't shown much interest in the >security mechanisms available in SIP versus operating in effectively >private environments. These identity spoofing concerns show a limitation >of transitive trust in these private communities. > >>> If I understand the RFC 4474 model correctly, a validated Identity >>>field has the semantics of asserting that the From field is valid. So >>>the assertion is not limited to the owner of the From field value. >>>Correct? While such a model is understandable, it dramatically >>>increases the reputation-management complexity of the task. I'm not >>>aware of an extant service over the public Internet of similar >>>complexity. > >We weren't exactly proposing a domain assurance council or something like >that. The authorization decision was supposed to be checking the reference >integrity of the domain in the From header field against the domain in the >subjectAltName of the cert (provided the cert is valid and the root >trusted): if there's a match, then this was signed for by the right >entity, if not, then not. I'm not sure what you mean by "not limited to >the owner of the From field value." In so far as the originating domain is >the "owner," then only they can sign it, if that's the limitation you're >concerned about. > >>>=20 >>> Better still is that it's the entity making the assertion that tells >>>the verifier where to look for verification information... What's seems >>>to be missing from the text in RFC 4474 is how the verifier can tell >>>whether the credential is a valid authorization for use of the From >>>field value. (If it wasn't clear before, now you can understand why I'm >>>curious about the concrete details of this authentication service.) >>I think the general idea was a DKIM-like model, so if the From field >>value is 'bob@foo.com', then you check the cert it points you to is for >>foo.com and signed by a CA you trust. That works for email-style names >>like that, because you can verify it's coming from foo.com, and foo.com >>is the authority for a 'bob@foo.com' name. (Assuming all CAs you trust >>are not compromised of course) > >Correct. The entity making the assertion tells the verifier where a cert >can be fetched, in the case that the verifier doesn't already have a cert >for the signer. Whether the cert is valid, or the CA itself is trusted by >the verifier, is however a different and prior question. > >>The hard part comes with E.164 numbers, because even if they appear as >>user@domain strings, like '+12125551212@foo.com', most SIP devices would >>treat it as an E.164 number - and that means it's not scoped to foo.com >>at all but rather a separate, global namespace that foo.com has no >>natural authority for. So with 4474 you'd have to believe foo.com is >>authoritative for the number based on reputation alone - i.e., you have a >>local list of domains you trust to claim E.164 numbers. That would work >>for a limited number of domain names, for example the domain names of the >>major carriers within a country, but it would fall apart quickly if we >>ever want Enterprises to sign, or international scenarios to work. > >Right. At the risk of waxing philosophical about it, I'd say that RFC4474 >took for granted the baseline assumption that RFC3263 would be how SIP >requests were routed. If you assume SIP requests get routed by taking the >domain portion of the request-URI and looking it up in the DNS to locate a >SIP server, RFC4474 probably isn't a bad fit for what you do. If however >SIP requests get routed based on the user portion of the Request-URI (like >a TN) without reference to the DNS, then probably having a domain sign for >identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty >much all about that. > >>So one proposal so far is that there would be certs which identify the >>E.164 numbers they're authoritative for (in a CN/SAN field for example), >>and that cert would be signed by some CA (or chain leading to one) that >>you trust. If it's a chain rather than directly signed by a CA, then >>it's not clear how one goes about retrieving the certs for the chain's >>links, and doing so could cause unacceptable delay. It also means we >>need revocation checks for the chain. And I'd argue the management >>aspects for this thing would be just as difficult as anything else >>proposed so far. > >Although I'm not the expert, my understanding is that there are various >cert chain compression techniques that could be applicable here. I've >squinted a bit at OCSP and other possible real-time revocation checks for >this as well. > >The exact amount of tolerable delay is a very interesting dimension of >this problem space. I suspect we have a considerable amount of time, given >all the human expectations about both post-dial delay and the wait for >someone to pick up after altering. I think it's enough time to perform >some non-trivial operations. > >But I do agree that there's no such thing as a free lunch, and that >implementing a credential system for telephone numbers, even just in a >single nation state, is operationally complex. In my day job, we have a >few different credentials today that carriers can use to interface with >various NANPA/NPAC system, and some of them already have requirements >similar to what we've discussed here, like delegation for example. I think >if we go down this STIR path, at the end of the day we'll end up with a >system that relies on many numbers aggregated behind a single credential, >on signatures and validations being performed by network elements much >more so than endpoints, and similar optimizations. Provided we can do this >without making e2e security impracticable, I think we'll be on the right >track. > >Jon Peterson >Neustar, Inc. > >>-hadriel >> > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From dhc2@dcrocker.net Sun Jun 16 17:49: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 A172221F9DD8 for ; Sun, 16 Jun 2013 17:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 AdJ-Ig0fF1xQ for ; Sun, 16 Jun 2013 17:49:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D998721F9DD5 for ; Sun, 16 Jun 2013 17:49:11 -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 r5H0n7GO026788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 17:49:10 -0700 Message-ID: <51BE5CF6.8070709@dcrocker.net> Date: Sun, 16 Jun 2013 17:48:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 16 Jun 2013 17:49:10 -0700 (PDT) Cc: "stir@ietf.org" , Hadriel Kaplan , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 00:49:21 -0000 On 6/16/2013 4:27 PM, Peterson, Jon wrote: >>> If I understand the RFC 4474 model correctly, a validated Identity >>> field has the semantics of asserting that the From field is valid. So >>> the assertion is not limited to the owner of the From field value. >>> Correct? While such a model is understandable, it dramatically >>> increases the reputation-management complexity of the task. I'm not >>> aware of an extant service over the public Internet of similar >>> complexity. > > We weren't exactly proposing a domain assurance council or something like DAC merely worked on a standardized query mechanism; it was not a service. But as far as defining a reputation-reporting service, actually you are. You are defining the ability of a third-party to vouch for a caller-id value that is not (necessarily) their own. That's different from defining a mechanism that let's someone assert direct ownership. > that. The authorization decision was supposed to be checking the reference > integrity of the domain in the From header field against the domain in the > subjectAltName of the cert (provided the cert is valid and the root > trusted): if there's a match, then this was signed for by the right That seems to be the first reference to the specific field in the cert, and assigning specific semantics to it. Any chance this is part of an existing spec relating to STIR? In any event, note that a premise of the model you've been describing is that the guy being validated gets to tell you where to look for the validation. That seems an odd trust model. I'd normally expect the verifying agent to choose the server with validation information separately. > entity, if not, then not. I'm not sure what you mean by "not limited to > the owner of the From field value." In so far as the originating domain is > the "owner," then only they can sign it, if that's the limitation you're > concerned about. That's not what RFC 4474 specifies, according to my reading of it: Section 4: The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to assert the identity that is populated in the From header field. "authorized to assert" does not have the same semantics as "is the owner of". Section 5, Step 2: The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the identity field. ditto. What you've defined permits multiple, separate third-parties to be able to make validity assertions about the use of the caller-id value. > Correct. The entity making the assertion tells the verifier where a cert > can be fetched, in the case that the verifier doesn't already have a cert > for the signer. Whether the cert is valid, or the CA itself is trusted by > the verifier, is however a different and prior question. When I ask someone for money, I think it's really nice that I get to tell them who to talk to, to vouch for my credit-worthiness... > Right. At the risk of waxing philosophical about it, I'd say that RFC4474 > took for granted the baseline assumption that RFC3263 would be how SIP > requests were routed. The idea that an authorization-checking mechanism would somehow depend upon the SIP routing service doesn't make obvious sense to me. Consequently I do not see how it should/can/will affect choice of the validation query service. >> So one proposal so far is that there would be certs which identify the >> E.164 numbers they're authoritative for (in a CN/SAN field for example), >> and that cert would be signed by some CA (or chain leading to one) that >> you trust. If it's a chain rather than directly signed by a CA, then >> it's not clear how one goes about retrieving the certs for the chain's >> links, and doing so could cause unacceptable delay. It also means we >> need revocation checks for the chain. And I'd argue the management >> aspects for this thing would be just as difficult as anything else >> proposed so far. > > Although I'm not the expert, my understanding is that there are various > cert chain compression techniques that could be applicable here. I've > squinted a bit at OCSP and other possible real-time revocation checks for > this as well. The essential point behind this line of discussion is that an entirely new cert semantic and trust structure will need to be invented and deployed. Note that this must be globally integrated and openly accessible. > But I do agree that there's no such thing as a free lunch, and that > implementing a credential system for telephone numbers, even just in a > single nation state, is operationally complex. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Sun Jun 16 18:51: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 8F2EC21F9AB8 for ; Sun, 16 Jun 2013 18:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 H2hMvvDfMVqd for ; Sun, 16 Jun 2013 18:51:04 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0BA21F9977 for ; Sun, 16 Jun 2013 18:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371433754; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=K6UoxrtzUG 1UIHNiOgcei+VsMa8KNNY4ocUmxyKP1JI=; b=C+qGAbr6L+i0zSBVYPdu/M5F7x pyRDC2KBbZpc7Emd223lZq8qrg3r9aO/BD3FBKHKonfxKujGeg5y5fGU+Dsg== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19602771; Sun, 16 Jun 2013 21:49:13 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Sun, 16 Jun 2013 21:50:51 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAIv1AP//m/SA Date: Mon, 17 Jun 2013 01:50:51 +0000 Message-ID: In-Reply-To: <51BE5CF6.8070709@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: xuBMT2+SL7XYnNqR0bFWeg== Content-Type: text/plain; charset="us-ascii" Content-ID: <2482319F522BC64D8115ED226BD5E425@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] current draft 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, 17 Jun 2013 01:51:08 -0000 >You are defining the ability of a third-party to vouch for a caller-id >value that is not (necessarily) their own. I'll speak this below, but I don't think we're on the same page here about who is a third party versus a first party to the names in question. >That's different from defining a mechanism that let's someone assert >direct ownership. > > >> that. The authorization decision was supposed to be checking the >>reference >> integrity of the domain in the From header field against the domain in >>the >> subjectAltName of the cert (provided the cert is valid and the root >> trusted): if there's a match, then this was signed for by the right > >That seems to be the first reference to the specific field in the cert, >and assigning specific semantics to it. Any chance this is part of an >existing spec relating to STIR? It's in RFC4474, and as far as I remember not nuked (yet anyway) from RFC4474bis. >In any event, note that a premise of the model you've been describing is >that the guy being validated gets to tell you where to look for the >validation. That seems an odd trust model. I'd normally expect the >verifying agent to choose the server with validation information >separately. I addressed that in my last mail. The "guy being validated" provides a pointer to the cert, yes, but whether or not you trust that cert is a fact about your relationship to the CA that issued it. The relying party only dereferences the Identity-Info header if they don't already have the cert by some other means. What happens if the guy being validated provides a problem cert in that link? Then the validation fails and nothing untoward happens. This is not a problem. >> entity, if not, then not. I'm not sure what you mean by "not limited to >> the owner of the From field value." In so far as the originating domain >>is >> the "owner," then only they can sign it, if that's the limitation you're >> concerned about. > >That's not what RFC 4474 specifies, according to my reading of it: > > Section 4: > > The authentication service authenticates Alice (possibly by sending a > Digest authentication challenge) and validates that she is authorized > to assert the identity that is populated in the From header field. > > >"authorized to assert" does not have the same semantics as "is the owner >of". Alice is not the signer, or owner, in this use case; the authentication service is implemented by an intermediary. The intermediary is the "owner" (in the sense I'm guessing you) of the domain name that appears in the URI Alice puts in her From header field. I don't want to get too entrenched in terminology that we're unlikely to use here, but Alice only "owns" her URI to my mind in so far as it was allocated to her by the owner of the domain name - they get to choose who gets to be jon@example.com and who gets to be dave@example.com. If they decide they don't like me anymore, jon@example.com can vanish in the blink of an eye. > Section 5, Step 2: > > The authentication service MUST determine whether or not the sender > of the request is authorized to claim the identity given in the > identity field. > >ditto. > >What you've defined permits multiple, separate third-parties to be able >to make validity assertions about the use of the caller-id value. What we've defined allows the owner of example.com to decide who gets to be jon@example.com and who gets to be dave@example.com. It doesn't allow multiple entities to be example.com. There are harder edges in this neighborhood when we look at subdomains (sip.example.com) and other delegation structures, but at the level you're discussing, it doesn't have the properties you're describing. >> Correct. The entity making the assertion tells the verifier where a cert >> can be fetched, in the case that the verifier doesn't already have a >>cert >> for the signer. Whether the cert is valid, or the CA itself is trusted >>by >> the verifier, is however a different and prior question. > >When I ask someone for money, I think it's really nice that I get to >tell them who to talk to, to vouch for my credit-worthiness... I've already explained above (and in my previous mail) that the ability to supply a pointer to a certificate does not cause relying parties to trust that certificate - trust anchors provisioned at the relying parties do. If the signer provides an untrustworthy certificate, then it won't be trusted. Now that much said, if the relying party trusts thousands of trust anchors a la web PKI and we're in that space, then sure, there's always the potential for mischief we've seen lately in web PKI. That potential would exist regardless of the presence of the Identity-Info header and its URI. The problem statement draft already discusses this and talks about how, if there would be certificates for telephone numbers, we should try to address it. >> Right. At the risk of waxing philosophical about it, I'd say that >>RFC4474 >> took for granted the baseline assumption that RFC3263 would be how SIP >> requests were routed. > >The idea that an authorization-checking mechanism would somehow depend >upon the SIP routing service doesn't make obvious sense to me. >Consequently I do not see how it should/can/will affect choice of the >validation query service. It's a subtle point, again dancing around the questions you were raising about "owning" names. One of the reasons RFC4474 adopted the design it did was because the "owner" of example.com controls what traffic goes to jon versus dave in the RFC3263 model, and authenticates jon or dave when they register to receive traffic. The trust relationships that were built for that served as a model for the use case you were reviewing above, where Alice authenticates to a local intermediary that instantiates the RFC4474 authentication service role. In cases where those registration concepts and routing concepts don't conform to the expectations of RFC3263 (which includes routing to E.164 numbers), the assumptions of RFC4474 break down. Just giving more color on why RFC4474 didn't set the world on fire. >>> So one proposal so far is that there would be certs which identify the >>> E.164 numbers they're authoritative for (in a CN/SAN field for >>>example), >>> and that cert would be signed by some CA (or chain leading to one) that >>> you trust. If it's a chain rather than directly signed by a CA, then >>> it's not clear how one goes about retrieving the certs for the chain's >>> links, and doing so could cause unacceptable delay. It also means we >>> need revocation checks for the chain. And I'd argue the management >>> aspects for this thing would be just as difficult as anything else >>> proposed so far. >> >> Although I'm not the expert, my understanding is that there are various >> cert chain compression techniques that could be applicable here. I've >> squinted a bit at OCSP and other possible real-time revocation checks >>for >> this as well. > >The essential point behind this line of discussion is that an entirely >new cert semantic and trust structure will need to be invented and >deployed. > >Note that this must be globally integrated and openly accessible. I'm not sure it's a new cert semantic, or a new trust structure, or that something needs to be "invented" to support this. Definitely agreed something needs to be deployed, and that it needs to be openly accessible. Global integration will come if it's successful, it won't come if it's not. Jon Peterson Neustar, Inc. >> But I do agree that there's no such thing as a free lunch, and that >> implementing a credential system for telephone numbers, even just in a >> single nation state, is operationally complex. > >+1 > >d/ > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From dhc@dcrocker.net Sun Jun 16 22:32: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 5AC0F21F9A59 for ; Sun, 16 Jun 2013 22:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 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 H-JjpBRIcQTI for ; Sun, 16 Jun 2013 22:32:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE1F21F9A10 for ; Sun, 16 Jun 2013 22:32:46 -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 r5H5WgSb032567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 22:32:45 -0700 Message-ID: <51BE9F6D.9030206@dcrocker.net> Date: Sun, 16 Jun 2013 22:32:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 16 Jun 2013 22:32:45 -0700 (PDT) Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 05:32:51 -0000 On 6/16/2013 6:50 PM, Peterson, Jon wrote: > > >> You are defining the ability of a third-party to vouch for a caller-id >> value that is not (necessarily) their own. > > I'll speak this below, but I don't think we're on the same page here about > who is a third party versus a first party to the names in question. Note that I'm not stating my own preference, but rather what the spec says. >> In any event, note that a premise of the model you've been describing is >> that the guy being validated gets to tell you where to look for the >> validation. That seems an odd trust model. I'd normally expect the >> verifying agent to choose the server with validation information >> separately. > > I addressed that in my last mail. The "guy being validated" provides a > pointer to the cert, yes, but whether or not you trust that cert is a fact > about your relationship to the CA that issued it. Then what is the point in having the pointer, rather than letting the validator decide where to get the cert from? I suspect the answer is that it's a search efficiency hack, rather than a required mechanism, helping to find a knowledgeable CA amongst potentially thousands. >>> entity, if not, then not. I'm not sure what you mean by "not limited to >>> the owner of the From field value." In so far as the originating domain >>> is >>> the "owner," then only they can sign it, if that's the limitation you're >>> concerned about. >> >> That's not what RFC 4474 specifies, according to my reading of it: >> >> Section 4: >> >> The authentication service authenticates Alice (possibly by sending a >> Digest authentication challenge) and validates that she is authorized >> to assert the identity that is populated in the From header field. >> >> >> "authorized to assert" does not have the same semantics as "is the owner >> of". > > Alice is not the signer, or owner, in this use case; the authentication > service is implemented by an intermediary. The intermediary is the "owner" > (in the sense I'm guessing you) of the domain name that appears in the URI > Alice puts in her From header field. I don't want to get too entrenched in > terminology that we're unlikely to use here, but Alice only "owns" her URI > to my mind in so far as it was allocated to her by the owner of the domain > name - they get to choose who gets to be jon@example.com and who gets to > be dave@example.com. If they decide they don't like me anymore, > jon@example.com can vanish in the blink of an eye. That has become nicely confusing (for me.) The basic entity of interest is the phone number. The basic ownership of internet is for the phone number. Who owns the validating service is (or, for this topic, should be) secondary. >> Section 5, Step 2: >> >> The authentication service MUST determine whether or not the sender >> of the request is authorized to claim the identity given in the >> identity field. >> >> ditto. >> >> What you've defined permits multiple, separate third-parties to be able >> to make validity assertions about the use of the caller-id value. > > What we've defined allows the owner of example.com to decide who gets to > be jon@example.com and who gets to be dave@example.com. It doesn't allow > multiple entities to be example.com. That's not the constraint I read in the RFC. What you've just described here is ownership of the string being validated. In the SIP case, that means ownership of the phone number. RFC 4474 does not specify that, according to my reading of it. > Now that much said, if the relying party trusts thousands of trust anchors > a la web PKI and we're in that space, then sure, there's always the > potential for mischief we've seen lately in web PKI. As I understand it, this model of thousands of trust anchors is showing some very rough edges for scaling, accuracy, and scope. I believe it also has had a single semantic, unrelated to the one being proposed. >> The idea that an authorization-checking mechanism would somehow depend >> upon the SIP routing service doesn't make obvious sense to me. >> Consequently I do not see how it should/can/will affect choice of the >> validation query service. > > It's a subtle point, again dancing around the questions you were raising > about "owning" names. One of the reasons RFC4474 adopted the design it did > was because the "owner" of example.com controls what traffic goes to jon > versus dave in the RFC3263 model, and authenticates jon or dave when they > register to receive traffic. I think I'm beginning to understand: The provider that is giving SIP service is the one that vouches for its use. In effect, the provider has the authority of the number owner, rather than the user to whom the number is assigned. That's not subtle; it's quite basic. It would be like requiring that my ISP be the one that vouches for my use of my domain name. > The trust relationships that were built for > that served as a model for the use case you were reviewing above, where > Alice authenticates to a local intermediary that instantiates the RFC4474 This sounds like a transitive trust model based on trust amongst telcos. > authentication service role. In cases where those registration concepts > and routing concepts don't conform to the expectations of RFC3263 (which > includes routing to E.164 numbers), the assumptions of RFC4474 break down. > Just giving more color on why RFC4474 didn't set the world on fire. +1 >> The essential point behind this line of discussion is that an entirely >> new cert semantic and trust structure will need to be invented and >> deployed. >> >> Note that this must be globally integrated and openly accessible. > > I'm not sure it's a new cert semantic, or a new trust structure, or that > something needs to be "invented" to support this. Feel free to point to instances of each that are deployed and used. Absent that, we can all be quite sure that all three assertions are... valid. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Sun Jun 16 23:18: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 A32AD21F9A88 for ; Sun, 16 Jun 2013 23:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 7h4wIHn+wqMM for ; Sun, 16 Jun 2013 23:18:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 036CF21F999E for ; Sun, 16 Jun 2013 23:18:20 -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 r5H6ICeU005245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 06:18:13 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 r5H6IC5t011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:18:12 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5H6ICR2011470; Mon, 17 Jun 2013 06:18:12 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-171-126.vpn.oracle.com (/10.154.171.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Jun 2013 23:18:11 -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: <4C2FC962-375E-4886-A15A-100E0031FE2D@cs.columbia.edu> Date: Mon, 17 Jun 2013 02:18:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62BC978C-4C84-42CB-B1ED-C71209956B33@oracle.com> References: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com> <4C2FC962-375E-4886-A15A-100E0031FE2D@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 06:18:27 -0000 On Jun 16, 2013, at 5:39 PM, Henning Schulzrinne = wrote: >> I mean ultimately some of us might want to actually implement the = signing and verification into our systems. If it uses public-key = signatures, then we need a standardized protocol by which our systems = can query for a certificate signed by some authority we trust for a = given E.164 number. If DNS tells us "go look over at FOO": then what = standardized protocol does FOO use that we need to implement? >=20 > Wouldn't plain HTTPS do the trick, as in 4474? Of course that's one possibility - my only point was we can't just make = the solution be "have DNS refer to another database"; we have to specify = what that referred-to database protocol would be so we can use it. And = if we're going to do that, then just stick that URL in the Identity-Info = header and avoid DNS. One of the advantages of the DNS proposal was the = DNS would *be* the database access protocol, and we wouldn't need a URL = in the Identity-Info header - we wouldn't even need the header at all. > * Very small number of entities (1-10ish per country code) sign = "public key X is entitled to use TN [range] A". The cert is conveyed in = some proprietary fashion to the number holder, similar to how today's = web CA's deliver certs to their customers. A single entity can have any = number of public keys, if they want to obscure their number holdings or = for operational reasons. Working group to-do: Define appropriate X.509 = content for numbers. The "magic" part of that which I was referring to was how a CA would = know what entities are entitled to what TNs, and for which various = country-codes. For example, let's assume Thawte is a trusted CA for = E.164's for +1 NANP... when some mom&pop "carrier" gets a number ported = into them, how does the process work to get Thawte to agree that mom&pop = now owns the ported number, and that the previous CA (if it's different) = revokes it for its previous carrier? When mom&pop get a number block, = how does Thawte verify that? > * Small number of "convenience" database providers host certs, = including possibly carriers (if they don't care about identifying = themselves). The database providers offer scaling and access control. = National policy decides what kind of access needs to be granted to whom = (fees, non-discrimination, etc.). > * Certs are retrieved via the HTTPS URL that's included in 4474bis = header. Clearly, the entity doing the signing has to know where to find = the cert, but as long as the number of entities signing is small, this = seems quite manageable. I'm not so sure. If we actually use the literal URL to get the cert, = then all the HTTPS servers have to be accessible to any querying device = of any carrier in the World. That doesn't scale if "access control" is = involved and charging for it. If we expect some service bureaus act as = middlemen for this retrieval instead, to alleviate the headache of = billing and access control between all carriers in the world, then we = have to create some standard way for the devices in the carriers to talk = to the middlemen and give them the URL for each call and get the cert or = have the signature verified; and that's assuming that their particular = middleman has a relationship with all databases in the World to access = the URL, or else they too have to use a protocol to give the URL to = another middleman, etc. Besides which the possible charging models for this thing probably needs = to be discussed. I'm not sure it makes sense for the caller side to = charge the called side to verify the caller-id it sent; nor vice-versa. = I'm all for letting each nation decide how to manage their numbers and = certs and authority model and so on, but letting each determine fees for = every other nation worries me in terms of the viability of getting this = to happen. I'm no expert in that area, but I would think it would be a = lot messier to get this stuff done if charging money between nations is = involved. It'd almost be better to make that not possible, and if a = nation doesn't want to play along and have its caller-ids verifiable by = everyone else then so be it. > * The validator knows trusted root CAs. Future work: A DANE-like = mechanism to list those, e.g., based on prefixes (e.g., +1 might list = the number administrator(s) in the US and other +1 countries). As long = as the number of CAs for each country code prefix is very small (which = seems likely, at least initially), there's no great need to have = references for each TN, while still preventing the Nigerian NRA signing = +1 numbers. > It might be interesting to see how much of EPP is applicable here. > As far as I can tell, assuming 4474bis header mods and the X.509 = customs, you could build a system that allows interoperable validation. = The only proprietary piece, initially, would be the cert delivery to the = number holder. > Is that a bit less magic? Almost all of that lends itself to having the certs simply be in the = DNS. There's nothing secret about the certs - they don't need to convey = any information about the organization that has the E.164 and signs the = SIP message using the private key. And the organization that has the = E.164 and signs doesn't even need a copy of the cert, because they never = give it to anyone themselves - they use the private key to sign the SIP = message stuff, while the public DNS serves the cert and thus its public = key to anyone asking; the only thing they need is a way to give the = public key (or pre-signed cert info) to the DNS to be installed there = for the E.164 numbers they own. The advantages of using the DNS as the repository for the cert data, = instead of giving an HTTP URL in a header to get a cert from, are: 1) There's no header needed for carrying a URL. 2) There's no need to worry about revocation, because the instant a = number changes ownership, the DNS entry of its cert changes. 3) There're far fewer potential CAs to have to trust - ideally only one = per country-code, the same one that's authoritative for its country-code = branch of the DNS tree; and we'd be using DNSSEC so its cert is in the = DNS, and it's the signer of its entries. In fact you might be able to = just have the raw public key in the DNS instead of the whole cert, = because the rest of the DNSSEC-provided info is redundant with the stuff = in a cert for this use-case. 4) It's generally faster, and with tighter client control for = retransmit/timeout because it's UDP. 5) For bigger carriers, they can have local DNS servers with copies of = the frequently accessed data (e.g., local nation E.164s) that their = verification systems can query. -hadriel From hadriel.kaplan@oracle.com Sun Jun 16 23:18: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 0D98421F9A8B for ; Sun, 16 Jun 2013 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 C0ga8G6yDREl for ; Sun, 16 Jun 2013 23:18:32 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16B21F9A87 for ; Sun, 16 Jun 2013 23:18:32 -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 r5H6IOJc013589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 06:18:25 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 r5H6IQQ2004530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:18:27 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 r5H6IQKU012664; Mon, 17 Jun 2013 06:18:26 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-171-126.vpn.oracle.com (/10.154.171.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Jun 2013 23:18:26 -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: Mon, 17 Jun 2013 02:18:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 17 Jun 2013 06:18:39 -0000 On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" = wrote: > The exact amount of tolerable delay is a very interesting dimension of > this problem space. I suspect we have a considerable amount of time, = given > all the human expectations about both post-dial delay and the wait for > someone to pick up after altering. I think it's enough time to perform > some non-trivial operations. I've been thinking about that and I'm not sure we actually have much = time. I've been looking at what the CNAM guys are doing, and at least = one them (used in a large mobile provider) goes so far as to sometimes = skip it on the INVITE and send their CNAM info in an UPDATE or INFO = afterwards due to the delay. I.e., they have us queue the INVITE while = they retrieve the CNAM info for the given caller-id, but if they take = too long then we send the INVITE and send their results separately = afterwards in another message. Another operator that uses private ENUM = for CNAM querying also sets very low timeouts on the query, and just = don't provide a calling name if it times out (ie., the INVITE gets sent = on without it, and nothing updates it later). Also, Brian at one point mentioned transit providers possibly doing the = verification check as well, and that might be difficult if it takes = non-trivial time I think, because one of the SLA measurements they get = ranked on is how fast they route their calls onward. (Besides which = they're never involved this type of stuff so I'd doubt they'd start now = anyway.) Anecdotally, I find that intra-nation calls get to ringing stage much = faster than international calls, so people are probably ok with = international caller-id verification taking longer. -hadriel From hadriel.kaplan@oracle.com Sun Jun 16 23:46: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 04A0421F9A91 for ; Sun, 16 Jun 2013 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 0m4YSD0NwFG7 for ; Sun, 16 Jun 2013 23:46:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 09C4821F9A8E for ; Sun, 16 Jun 2013 23:46: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 r5H6kDKC004982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 06:46:14 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 r5H6kFiv028057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:46:15 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5H6kFwn018009; Mon, 17 Jun 2013 06:46:15 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-171-126.vpn.oracle.com (/10.154.171.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Jun 2013 23:46:14 -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: <51BE9F6D.9030206@dcrocker.net> Date: Mon, 17 Jun 2013 02:46:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9019932F-C6A3-43B7-9F42-15CDF4A3C779@oracle.com> References: <51BE9F6D.9030206@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] current draft 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, 17 Jun 2013 06:46:27 -0000 On Jun 17, 2013, at 1:32 AM, Dave Crocker wrote: >> I addressed that in my last mail. The "guy being validated" provides = a >> pointer to the cert, yes, but whether or not you trust that cert is a = fact >> about your relationship to the CA that issued it. >=20 > Then what is the point in having the pointer, rather than letting the = validator decide where to get the cert from? > I suspect the answer is that it's a search efficiency hack, rather = than a required mechanism, helping to find a knowledgeable CA amongst = potentially thousands. No, for 4474 he was talking about the cert belonging to the SIP-identity = hash signer, not the CA that signed that cert as the trusted = root/issuer. For example if you receive a message with the =46rom of = 'alice@foo.com', then foo.com needs to tell you where to get its cert to = prove it is foo.com that signed the SIP =46rom of 'alice@foo.com'. As = the verifier, you have no direct relationship with foo.com, nor know = which trusted CA foo.com uses. So foo.com stores its cert at some web = server, which it tells you to get the cert from with this URL. If the = URL was changed by an evil middleman to give you a different cert, then = the cert won't be for 'foo.com' so verification correctly fails. An alternative could have been to just have you automatically go to = 'https://foo.com/sipcert' or some such thing, or have you look for some = DNS record for foo.com to tell you where to get the cert. But with the = URL being sent in the message then foo.com could use different certs for = different calls; for example if it uses different PBXs in multiple = branch offices, it could give them each unique keys to sign the SIP = messages with, without having to use separate domain names in its SIP = From. -hadriel From jon.peterson@neustar.biz Sun Jun 16 23:56: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 4321221F9A7C for ; Sun, 16 Jun 2013 23:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 nwCbt3YiWRTp for ; Sun, 16 Jun 2013 23:56:12 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2021F934C for ; Sun, 16 Jun 2013 23:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371452116; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=WjQsERd3IF qvFfBsBGUH8mvo1hszmSnkHtJqi80YZR4=; b=Eev/YyZzlpZBpk8NOZjipjw2uU 36yFbgQh0yH51hxnCAlsrHpqC4Bxc2IrifWoEkUeqbdERoNEzWI7RncJvO0g== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21045178; Mon, 17 Jun 2013 02:55:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 02:56:02 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAIv1AP//m/SAgACzSID//6H7gA== Date: Mon, 17 Jun 2013 06:56:01 +0000 Message-ID: In-Reply-To: <51BE9F6D.9030206@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +ko8EoGItpLo8zieJiUCuw== Content-Type: text/plain; charset="us-ascii" Content-ID: <7546C63C1F69BC4C90FD37733E2EBFAD@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] current draft 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, 17 Jun 2013 06:56:16 -0000 On 6/16/13 10:32 PM, "Dave Crocker" wrote: >[snip] >> >> I addressed that in my last mail. The "guy being validated" provides a >> pointer to the cert, yes, but whether or not you trust that cert is a >>fact >> about your relationship to the CA that issued it. > >Then what is the point in having the pointer, rather than letting the >validator decide where to get the cert from? > >I suspect the answer is that it's a search efficiency hack, rather than >a required mechanism, helping to find a knowledgeable CA amongst >potentially thousands. I wouldn't say that's an unfair characterization. It gives the verification service quick and easy access to the right cert, provided of course that the signer provides the right cert. Otherwise there would have to be some kind of cert discovery process implemented by the verification service. >> >> Alice is not the signer, or owner, in this use case; the authentication >> service is implemented by an intermediary. The intermediary is the >>"owner" >> (in the sense I'm guessing you) of the domain name that appears in the >>URI >> Alice puts in her From header field. I don't want to get too entrenched >>in >> terminology that we're unlikely to use here, but Alice only "owns" her >>URI >> to my mind in so far as it was allocated to her by the owner of the >>domain >> name - they get to choose who gets to be jon@example.com and who gets >>to >> be dave@example.com. If they decide they don't like me anymore, >> jon@example.com can vanish in the blink of an eye. > >That has become nicely confusing (for me.) > >The basic entity of interest is the phone number. The basic ownership >of internet is for the phone number. Perhaps this has become confusing for you because RFC4474 doesn't make any real provision for telephone numbers, but you're trying to read telephone numbers into the RFC4474 text. Think like RFC4474 is only talking about user@domain URIs. The proposed STIR work is, in part, to broaden the scope of identity protection to include telephone numbers. > >Who owns the validating service is (or, for this topic, should be) >secondary. > > >>> Section 5, Step 2: >>> >>> The authentication service MUST determine whether or not the sender >>> of the request is authorized to claim the identity given in the >>> identity field. >>> >>> ditto. >>> >>> What you've defined permits multiple, separate third-parties to be able >>> to make validity assertions about the use of the caller-id value. >> >> What we've defined allows the owner of example.com to decide who gets to >> be jon@example.com and who gets to be dave@example.com. It doesn't allow >> multiple entities to be example.com. > >That's not the constraint I read in the RFC. What you've just described >here is ownership of the string being validated. In the SIP case, that >means ownership of the phone number. RFC 4474 does not specify that, >according to my reading of it. RFC4474 does not cover telephone numbers - we propose to fix that with this new work. >> Now that much said, if the relying party trusts thousands of trust >>anchors >> a la web PKI and we're in that space, then sure, there's always the >> potential for mischief we've seen lately in web PKI. > >As I understand it, this model of thousands of trust anchors is showing >some very rough edges for scaling, accuracy, and scope. I believe it >also has had a single semantic, unrelated to the one being proposed. Right, the rough edges there are why the current problem statement for STIR suggests we do things a bit differently. >>> The idea that an authorization-checking mechanism would somehow depend >>> upon the SIP routing service doesn't make obvious sense to me. >>> Consequently I do not see how it should/can/will affect choice of the >>> validation query service. >> >> It's a subtle point, again dancing around the questions you were raising >> about "owning" names. One of the reasons RFC4474 adopted the design it >>did >> was because the "owner" of example.com controls what traffic goes to jon >> versus dave in the RFC3263 model, and authenticates jon or dave when >>they >> register to receive traffic. > >I think I'm beginning to understand: The provider that is giving SIP >service is the one that vouches for its use. In effect, the provider >has the authority of the number owner, rather than the user to whom the >number is assigned. Almost - again, RFC4474 doesn't cover telephone numbers, and neither did RFC3263. >That's not subtle; it's quite basic. It would be like requiring that my >ISP be the one that vouches for my use of my domain name. If your ISP actually owned your domain name instead of you, sure. If in fact you own your own domain name, RFC4474 lets you (as in, your UA) act as your authentication service. The authentication service is a logical function that can be instantiated by either the UA or an intermediary. Who should do it depends pretty much entirely on who owns the domain name. Do I own the email address "jon.peterson@neustar.biz"? No, Neustar owns it. I use it at their pleasure. If our IT staff wanted to, they could send all my email to someone else in the company. I do own my own domain names, though, and I control who gets what account under them. Since there are similar use cases for SIP, we included this use case in RFC4474. >> The trust relationships that were built for >> that served as a model for the use case you were reviewing above, where >> Alice authenticates to a local intermediary that instantiates the >>RFC4474 > >This sounds like a transitive trust model based on trust amongst telcos. Not really. example.com gets to vouch for example.com addresses, and the signature they add is end-to-end visible to verification services implemented at intermediaries or at terminating endpoints. >> authentication service role. In cases where those registration concepts >> and routing concepts don't conform to the expectations of RFC3263 (which >> includes routing to E.164 numbers), the assumptions of RFC4474 break >>down. >> Just giving more color on why RFC4474 didn't set the world on fire. > >+1 > > >>> The essential point behind this line of discussion is that an entirely >>> new cert semantic and trust structure will need to be invented and >>> deployed. >>> >>> Note that this must be globally integrated and openly accessible. >> >> I'm not sure it's a new cert semantic, or a new trust structure, or that >> something needs to be "invented" to support this. > >Feel free to point to instances of each that are deployed and used. The structures that underly trust in the proposed STIR work are simply the extent ones in the telephone network. There are currently number block assignees, delegates of those assignees, and ultimately end users who possess numbers. Databases exist that contain all that information, and credentials exist that reflect those scopes of authority. The proposed work is only to leverage those structures. Certs have I believe had the capacity to contain telephone numbers since X.520 or so. Jon Peterson Neustar, Inc. >Absent that, we can all be quite sure that all three assertions are... >valid. > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From jon.peterson@neustar.biz Mon Jun 17 00:07: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 4D81921F9AAB for ; Mon, 17 Jun 2013 00:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.244 X-Spam-Level: X-Spam-Status: No, score=-106.244 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 lB6sgfEzby5d for ; Mon, 17 Jun 2013 00:07:41 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DD0AC21F9AA1 for ; Mon, 17 Jun 2013 00:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371452801; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=BxgdiQjoA0 Rvw1FwiwYlgGBI8uFJ7EKSggISjsll81w=; b=YufRUtgAj6/KFnKfgd9TDudvPd pg/Ww3BUP45cy6sya5F67Sd97VAj2hOzmsFT2hwAZTqVX35Zig80a6eBKtFQ== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21045721; Mon, 17 Jun 2013 03:06:40 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 03:07:25 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Henning Schulzrinne Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKA Date: Mon, 17 Jun 2013 07:07:23 +0000 Message-ID: In-Reply-To: <62BC978C-4C84-42CB-B1ED-C71209956B33@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ctwVTxaHZiMg5VSYdiyPpA== Content-Type: text/plain; charset="us-ascii" Content-ID: <7FD03B64C79925438DB8E402642744D5@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 07:07:46 -0000 I think the advantages below, with the exception of 4, would be true of any golden root we created for whatever protocol, be it HTTP or something else. I'm sure I could define an HTTP golden root such that the verification service could synthesize the proper fetch request from the URI in the From with an Identity-Info, one that updated in real time so you never needed to worry about revocation, one for which there was only one CA, and which you could locally cache (well, okay, 5 does conflict a bit with 2).=20 Also, all of the (snipped) concerns you raised about access control, middlemen, charging, etc are just as likely to arise for DNS as for any other proposal. Now that much said, I'm not convinced HTTP is the end-all-be-all for Identity-Info. I had high hopes for CID when RFC4474 was written. But more seriously, I don't think we should rule out DNS as an access method for credentials at this stage. Even if we were just copying public keys out of certs from a cert store into the appropriate node of the DNS, and totally duplicating effort, if that helped adoption for some use cases it would probably be worth it. Maybe some of Henning's "convenience" databases could take this form. Jon Peterson Neustar, Inc. >The advantages of using the DNS as the repository for the cert data, >instead of giving an HTTP URL in a header to get a cert from, are: >1) There's no header needed for carrying a URL. >2) There's no need to worry about revocation, because the instant a >number changes ownership, the DNS entry of its cert changes. >3) There're far fewer potential CAs to have to trust - ideally only one >per country-code, the same one that's authoritative for its country-code >branch of the DNS tree; and we'd be using DNSSEC so its cert is in the >DNS, and it's the signer of its entries. In fact you might be able to >just have the raw public key in the DNS instead of the whole cert, >because the rest of the DNSSEC-provided info is redundant with the stuff >in a cert for this use-case. >4) It's generally faster, and with tighter client control for >retransmit/timeout because it's UDP. >5) For bigger carriers, they can have local DNS servers with copies of >the frequently accessed data (e.g., local nation E.164s) that their >verification systems can query. > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Mon Jun 17 00:24: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 CF9C421F88EA for ; Mon, 17 Jun 2013 00:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 cn9E6yXkDPAq for ; Mon, 17 Jun 2013 00:24:41 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7257621F9AB7 for ; Mon, 17 Jun 2013 00:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371453830; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=8Gtt384Xkm zOlX2g/zxZ+ICfJ2ecb6AWIXnfDlhwAgU=; b=GqByiL1zv9BhHM3g98m0Cwi1LU OKrS21c7ov9fZ1/2uYX7Os356yC836bKD2Ob+/KaQM4hFJH7UhHiuZ46KFzQ== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21046680; Mon, 17 Jun 2013 03:23:49 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 03:24:37 -0400 From: "Peterson, Jon" To: "philippe.fouquart@orange.com" , "stir@ietf.org" Thread-Topic: current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxzvcAgAeIGwA= Date: Mon, 17 Jun 2013 07:24:36 +0000 Message-ID: In-Reply-To: <27770_1371030649_51B84479_27770_127_1_B5939C6860701C49AA39C5DA5189448B0A2BA6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ym27EGjl6Hpg0j6pqi5ryg== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] current draft 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, 17 Jun 2013 07:24:47 -0000 I don=B9t think I previously replied to say, works for me. Those fixes are added. Jon Peterson Neustar, Inc. On 6/12/13 2:50 AM, "philippe.fouquart@orange.com" wrote: >Jon, > >The only comment I would have is on the general phrasing of the first >paragraph, which at least for an outsider, may sometimes seem to be >focused on anonymous calls rather than on 'illegitimate' CPNs in general >(whilst the "more serious" problems that are listed there have indeed >more to do with the latter than the former). > >If this restriction is not deliberate, maybe you want to say "can be >hidden or forged" instead of only "hidden" and "that obscure or falsify" >as opposed to only "obscure". > >Regards, > >Philippe Fouquart >Orange Labs Networks >+33 (0) 1 45 29 58 13 > >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Peterson, Jon >Sent: Wednesday, June 12, 2013 3:03 AM >To: stir@ietf.org >Subject: [stir] current draft charter > > >Below is the current draft of the charter, based on our prior discussions. > >Jon Peterson >Neustar, Inc. > >---- > >Name: Secure Telephone Identity Revisited (stir) >Area: RAI > >Chairs: TBD >Area Advisor: TBD (Barnes) > >Mailing list: (current source-auth) >To Subscribe: -- > >Over the last decade, a growing set of problems have resulted from the >lack of security mechanisms for attesting the origins of real-time >communications. Many of these problems are familiar from our experience >with email: bulk unsolicited commercial communications remain a challenge >for the traditional telephone network largely because the source of calls >can be hidden. Others are potentially more serious: voicemail hacking, >impersonating banks and similar attacks are becoming commonplace. The >technologies that obscure the caller's identity are frequently gateways >between the telephone network and the Internet. > >SIP is one of the main VoIP technologies employed by these gateways. A >number of previous efforts have attacked the problem of securing the >origins of SIP communications, including RFC3325, RFC4474 and the VIPR >WG. To date, however, true cryptographic authentication of the source of >SIP calls has not seen any appreciable deployment. While several factors >contributed to this lack of success, two seem like the largest culprits: >1) the lack of any real means of asserting authority over telephone >numbers on the Internet; and 2) a misalignment of the integrity >mechanisms proposed by RFC4474 with the highly interworked, mediated and >policy-driven deployment environment that has emerged for SIP. The VIPR >alternative, while promising, faced apparently unavoidable privacy >problems and other significant deployment hurdles. > >Given the pressing difficulties caused by the lack of a useful identity >solution, the problem of securing the origins of SIP communication must >be revisited. Because SIP deployments are so closely tied to the >telephone network, we moreover must investigate solutions that can work >when one side of a call is in the PSTN - or potentially even both. This >will require a two-pronged approach: one prong relying on information >carried in SIP signaling; the other prong relying on forming out-of-band >connections between IP endpoints that are participating in a call. > >The changes to the RFC4474 approach to SIP signaling must include a new >capability for Identity assertions to cover telephone numbers, rather >than domain names. To conform with realistic deployments, we must also >study ways to rebalance the requirements for the scope of RFC4474's >integrity protection to emphasize preventing third-party impersonation >over preventing men-in-the-middle from capturing media. > >Finally, the solution must encompass an out-of-band means for endpoints >to establish identity when there is no direct SIP signaling path between >them available, due to interworking or similar factors. This working >group will investigate a means for Internet endpoints to discover one >another in real time to verify that a telephone call between them is in >progress based on minimal evidence or configuration. This architecture >will, to the degree that is possible, reuse the credentials defined for >telephone numbers for the in-band signaling solution, and define a >discovery mechanism that provides better than hop-by-hop security. > >The working group will coordinate with the security area on certificate >management. > >The working group will coordinate with RAI area groups studying the >problem of signaling through existing deployments, including INSIPID. > >Identity is closely linked to privacy, and frequently one comes at the >cost of the other. This working group is not chartered to mandate the >presence of identity in SIP requests, and to the extent feasible it will >find privacy-friendly solutions that leak minimal information about calls >to third parties. > >The working group will deliver the following: > >- A problem statement detailing the deployment environment and >difficulties motivate work on secure origins > >- A revision to SIP's identity features to provide several fixes: > Changes to support certification for telephone numbers > Changes to the signature > >- A document describing the certificate profile required to support >telephone numbers in certificates > >- A fallback mechanism to allow out-of-band identity establishment during >call setup > >Milestones > >Sep 2013 Submit problem statement for Info >Nov 2013 Submit RFC4474bis for PS >Jan 2013 Submit TN cert profile for Info >Mar 2014 Submit fallback for PS > > >__________________________________________________________________________ >_______________________________________________ > >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, >France Telecom - 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, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > From hgs@cs.columbia.edu Mon Jun 17 05:03: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 010A021F9AAC for ; Mon, 17 Jun 2013 05:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 BLya+GVWd01e for ; Mon, 17 Jun 2013 05:03:11 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id AB71A21F9992 for ; Mon, 17 Jun 2013 05:03:07 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5HC36CK006946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 08:03:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 17 Jun 2013 08:03:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48BB46E5-42EA-4241-8CEC-FD9F8C133088@cs.columbia.edu> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 12:03:18 -0000 It might be helpful to explicitly distinguish three models, independent = of whether the cert is stored in DNS or some HTTP-accessed data store: (1) Single CA per country code (CC); no chaining. All delegations and = multiple-use are explicitly generated by the CC CA, based on requests by = the primary holder of the number. (2) Single CA per country code, but with chaining. (3) Lots of CAs per country code, e.g., for proof-of-possession systems. = (Example: Existing webCAs get into the E.164 validation business.) I think we've been commingling the three in discussion, making the = trade-offs harder to identify. On #2 below (expiration), I'm not sure that it matters whether the entry = is stored in DNS or data store. With DNS and HTTP, you have to deal with = caching just the same. Also, for DNS, it would be helpful to be specific whether this is run by = one entity or, if not, how entries are doled out, given the lack of = natural hierarchy. On Jun 17, 2013, at 3:07 AM, Peterson, Jon wrote: >=20 > I think the advantages below, with the exception of 4, would be true = of > any golden root we created for whatever protocol, be it HTTP or = something > else. I'm sure I could define an HTTP golden root such that the > verification service could synthesize the proper fetch request from = the > URI in the =46rom with an Identity-Info, one that updated in real time = so > you never needed to worry about revocation, one for which there was = only > one CA, and which you could locally cache (well, okay, 5 does conflict = a > bit with 2).=20 >=20 > Also, all of the (snipped) concerns you raised about access control, > middlemen, charging, etc are just as likely to arise for DNS as for = any > other proposal. >=20 > Now that much said, I'm not convinced HTTP is the end-all-be-all for > Identity-Info. I had high hopes for CID when RFC4474 was written. But = more > seriously, I don't think we should rule out DNS as an access method = for > credentials at this stage. Even if we were just copying public keys = out of > certs from a cert store into the appropriate node of the DNS, and = totally > duplicating effort, if that helped adoption for some use cases it = would > probably be worth it. Maybe some of Henning's "convenience" databases > could take this form. >=20 > Jon Peterson > Neustar, Inc. >=20 >> The advantages of using the DNS as the repository for the cert data, >> instead of giving an HTTP URL in a header to get a cert from, are: >> 1) There's no header needed for carrying a URL. >> 2) There's no need to worry about revocation, because the instant a >> number changes ownership, the DNS entry of its cert changes. >> 3) There're far fewer potential CAs to have to trust - ideally only = one >> per country-code, the same one that's authoritative for its = country-code >> branch of the DNS tree; and we'd be using DNSSEC so its cert is in = the >> DNS, and it's the signer of its entries. In fact you might be able = to >> just have the raw public key in the DNS instead of the whole cert, >> because the rest of the DNSSEC-provided info is redundant with the = stuff >> in a cert for this use-case. >> 4) It's generally faster, and with tighter client control for >> retransmit/timeout because it's UDP. >> 5) For bigger carriers, they can have local DNS servers with copies = of >> the frequently accessed data (e.g., local nation E.164s) that their >> verification systems can query. >>=20 >> -hadriel >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 From hgs@cs.columbia.edu Mon Jun 17 05:15: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 058E221F9BA2 for ; Mon, 17 Jun 2013 05:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 lF0zCNGywJLx for ; Mon, 17 Jun 2013 05:14:49 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 190D421F9B77 for ; Mon, 17 Jun 2013 05:14:27 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5HCEKw8003096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 08:14:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> Date: Mon, 17 Jun 2013 08:14:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "Peterson, Jon" Subject: Re: [stir] current draft 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, 17 Jun 2013 12:15:01 -0000 I wouldn't be surprised if the large carriers cache all certs locally. = For +1, I'd suggest that's less than a TB, i.e., a single disk, even if = every number has their own cert, rather than number ranges. They would = then subscribe to a notification service for any porting-related = changes, given that such changes affect a very small fraction of the = numbers (quarterly churn of mobile carriers is about 1-2%). This can all = be done within the carrier network, i.e., without affecting the external = public data interface. On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote: >=20 > On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" = wrote: >=20 >> The exact amount of tolerable delay is a very interesting dimension = of >> this problem space. I suspect we have a considerable amount of time, = given >> all the human expectations about both post-dial delay and the wait = for >> someone to pick up after altering. I think it's enough time to = perform >> some non-trivial operations. >=20 > I've been thinking about that and I'm not sure we actually have much = time. I've been looking at what the CNAM guys are doing, and at least = one them (used in a large mobile provider) goes so far as to sometimes = skip it on the INVITE and send their CNAM info in an UPDATE or INFO = afterwards due to the delay. I.e., they have us queue the INVITE while = they retrieve the CNAM info for the given caller-id, but if they take = too long then we send the INVITE and send their results separately = afterwards in another message. Another operator that uses private ENUM = for CNAM querying also sets very low timeouts on the query, and just = don't provide a calling name if it times out (ie., the INVITE gets sent = on without it, and nothing updates it later). >=20 > Also, Brian at one point mentioned transit providers possibly doing = the verification check as well, and that might be difficult if it takes = non-trivial time I think, because one of the SLA measurements they get = ranked on is how fast they route their calls onward. (Besides which = they're never involved this type of stuff so I'd doubt they'd start now = anyway.) >=20 > Anecdotally, I find that intra-nation calls get to ringing stage much = faster than international calls, so people are probably ok with = international caller-id verification taking longer. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From dhc@dcrocker.net Mon Jun 17 08:41: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 7C10221F9CA2 for ; Mon, 17 Jun 2013 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 KEHoAYjf8U-0 for ; Mon, 17 Jun 2013 08:41:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA921F9984 for ; Mon, 17 Jun 2013 08:41:22 -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 r5HFfIc2019039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jun 2013 08:41:22 -0700 Message-ID: <51BF2E12.8070209@dcrocker.net> Date: Mon, 17 Jun 2013 08:41:06 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 17 Jun 2013 08:41:22 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 15:41:30 -0000 On 6/16/2013 11:56 PM, Peterson, Jon wrote: >> As I understand it, this model of thousands of trust anchors is showing >> some very rough edges for scaling, accuracy, and scope. I believe it >> also has had a single semantic, unrelated to the one being proposed. > > Right, the rough edges there are why the current problem statement for > STIR suggests we do things a bit differently. In looking over the draft charter that you circulated last Tuesday, I'm not seeing text that obviously covers this. In contrast, all of the list discussion about CAs appears to be based on the current model that uses very large numbers of anchors. Even with text in the charter, the deeper question is what changes are feasible to the current model that are viable with the scale, diversity and reliability needed for the proposed service? Absent a vetted design approach, it won't mean much to have a charter task covering it; in fact it will be more appropriate as an IRTF task... >> I think I'm beginning to understand: The provider that is giving SIP >> service is the one that vouches for its use. In effect, the provider >> has the authority of the number owner, rather than the user to whom the >> number is assigned. ... >> That's not subtle; it's quite basic. It would be like requiring that my >> ISP be the one that vouches for my use of my domain name. > > If your ISP actually owned your domain name instead of you, sure. If in > fact you own your own domain name, RFC4474 lets you (as in, your UA) act > as your authentication service. The authentication service is a logical > function that can be instantiated by either the UA or an intermediary. Who > should do it depends pretty much entirely on who owns the domain name. > > Do I own the email address "jon.peterson@neustar.biz"? No, Neustar owns > it. Number portability changes this. The number does not belong to the service provider. >> This sounds like a transitive trust model based on trust amongst telcos. > > Not really. example.com gets to vouch for example.com addresses, and the Unlike email addresses, the relationship between the service provider and the user is not built into the identifier. What you've been describing is an unspecified service in the background that establishing this relationship. It's key because it authorizes the provider to vouch for use of the number. >>> I'm not sure it's a new cert semantic, or a new trust structure, or that >>> something needs to be "invented" to support this. >> >> Feel free to point to instances of each that are deployed and used. > > The structures that underly trust in the proposed STIR work are simply the > extent ones in the telephone network. By way of considering edge cases, to the extent that this mechanism is going to validate uses of numbers for calls that do not originate from their home -- such as the mobile physician calling from someone else's phone -- the extant trust mechanisms don't cover them. In any event, the considerable barrier to adoption you've just described is adoption by all telcos. > There are currently number block > assignees, delegates of those assignees, and ultimately end users who > possess numbers. Databases exist that contain all that information, and > credentials exist that reflect those scopes of authority. The proposed > work is only to leverage those structures. Forgive me but I don't see any of that in the charter or discussions so far. It seems to be left as the "then a miracle happens" part of the specification. As such, it isn't possible to evaluate its practicality. On 6/17/2013 12:07 AM, Peterson, Jon wrote:> > I think the advantages below, with the exception of 4, would be true > of any golden root we created for whatever protocol, be it HTTP or > something else. I'm sure I could define an HTTP golden root such that The real point of practical leverage here is existing deployment. It's easy to 'define' almost anything. Getting deployment and adequate operational service is the hard part. > the verification service could synthesize the proper fetch request > from the URI in the From with an Identity-Info, one that updated in > real time so you never needed to worry about revocation, one for For any existing capability, I'm sure one can define a new service that contains it. The question is what risks and benefits come with that new effort? On 6/17/2013 5:03 AM, Henning Schulzrinne wrote: > It might be helpful to explicitly distinguish three models, > independent of whether the cert is stored in DNS or some HTTP-accessed > data store: Big +1 for this sort of analytic discipline in the effort... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Mon Jun 17 09:04: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 B413321F9CF5 for ; Mon, 17 Jun 2013 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 l9F6lsiTKnU5 for ; Mon, 17 Jun 2013 09:04: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 0A63D21F9D5D for ; Mon, 17 Jun 2013 09:04:14 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 09:04:13 -0700 From: Michael Hammer To: "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdA= Date: Mon, 17 Jun 2013 16:04:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_005D_01CE6B52.C6C78D60" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" Subject: Re: [stir] current draft 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, 17 Jun 2013 16:04:23 -0000 ------=_NextPart_000_005D_01CE6B52.C6C78D60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, I am following the thread and trying to grasp the heart of the matter. First point: This is about E.164 number delegation and proof of ownership. So, I find much of the discussion that seems to rely on DNS structure or Domain name structuring to be a distraction. How you prove proof of ownership of a domain is a separate, albeit twin problem. But, I think that is out of scope. I do not believe the answer here is to ask my evil twin if he owns the E.164. Second point: The delegation of E.164 numbers down the tree inextricable defines who owns the number, so any collection of certs into an authoritative repository MUST follow the same path back up, or you lose sight of that ownership. E.164 is already the hierarchy, so no second hierarchy is needed. The recipient of a number block or an individual number may need to receive the private key, else the carrier signs and inserts the signature on the path out from that user. (Note, still need to determine how many bytes constitute the signature such that it fits into an existing SS7 parameter. Perhaps the answer is to include an indicator in SS7 that the gateway to SIP must perform the signature outbound. But, that may limit this to a single hop, else need to trust follow-on SS7 networks to sign properly, but that may be acceptable.) Third point: The called party needs to unequivocally know how to validate an assertion and who to go to for the inputs to perform that validation. The how should be defined by the RFC, but the who ultimately depends on the root of each E.164 country code (see point 2). If the DNS is involved, I think that there is an IAB draft/RFC that says the DNS should not be used for all things. So, it is likely that the called party search would start with a well-known URI to the CC authority, communication to which could be secure, who could then point to one or more authoritative services, depending on how the out-sourcing is done, who have the official cert associated with the official delegation of E.164 number blocks or numbers. This seems to be a parallel to the number portability databases, except that one is now looking for a cert rather than a route to the serving carrier. I am not suggesting that the NP databases be used, as this could be orthogonal to that. Doing a search based on using the E.164 as an index should not be an issue, since in many cases a 10k block of numbers may point to a single cert. In those cases where portability occurs and single numbers have a different cert, the database could have an indicator of which 10k blocks require full E.164 search to be performed. (For international, blocks are defined by how many leading digits are used.) Fourth point: Lastly, so the called party has all the elements from the signaling with which to validate the signature, the RFC needs to specify what elements are prohibited from changing end-to-end. Given that some of the existing parameters do change in current systems, I don't know how you get around doing one of the following: - define new header that contains complete signature package that is added by whomever does the signing. - re-define existing headers to add the signature and restrict any intermediary from modifying those values. Seeing that the existing already have usage baggage, the first option seems more likely to succeed. Also, need to ensure that the SS7 network can carry elements E2E without changes. SS7 terminations may have to rely on the SIP-to-SS7 GW to perform validation. SIP terminations may have to rely on the SS7-to-SIP GW to generate signatures. SIP-SS7-SIP would be an issue given the "no change SS7" limitation. Did I miss any requirements or constraints here? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 17, 2013 8:14 AM To: Hadriel Kaplan Cc: stir@ietf.org; dcrocker@bbiw.net; Peterson, Jon Subject: Re: [stir] current draft charter I wouldn't be surprised if the large carriers cache all certs locally. For +1, I'd suggest that's less than a TB, i.e., a single disk, even if every number has their own cert, rather than number ranges. They would then subscribe to a notification service for any porting-related changes, given that such changes affect a very small fraction of the numbers (quarterly churn of mobile carriers is about 1-2%). This can all be done within the carrier network, i.e., without affecting the external public data interface. On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote: > > On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" wrote: > >> The exact amount of tolerable delay is a very interesting dimension >> of this problem space. I suspect we have a considerable amount of >> time, given all the human expectations about both post-dial delay and >> the wait for someone to pick up after altering. I think it's enough >> time to perform some non-trivial operations. > > I've been thinking about that and I'm not sure we actually have much time. I've been looking at what the CNAM guys are doing, and at least one them (used in a large mobile provider) goes so far as to sometimes skip it on the INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the delay. I.e., they have us queue the INVITE while they retrieve the CNAM info for the given caller-id, but if they take too long then we send the INVITE and send their results separately afterwards in another message. Another operator that uses private ENUM for CNAM querying also sets very low timeouts on the query, and just don't provide a calling name if it times out (ie., the INVITE gets sent on without it, and nothing updates it later). > > Also, Brian at one point mentioned transit providers possibly doing > the verification check as well, and that might be difficult if it > takes non-trivial time I think, because one of the SLA measurements > they get ranked on is how fast they route their calls onward. > (Besides which they're never involved this type of stuff so I'd doubt > they'd start now anyway.) > > Anecdotally, I find that intra-nation calls get to ringing stage much faster than international calls, so people are probably ok with international caller-id verification taking longer. > > -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_005D_01CE6B52.C6C78D60 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE2MDQxMFowIwYJKoZIhvcNAQkEMRYEFMgIullEivkp1/H5Fm6pxTzoyrzIMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAMnub7/+OygP5MmY51sGlV6CzBEu/odjIfEwyRHwX Djgw31NDutm6nZ55h7oqJ/YjAy4vB8G215jewzQyUExH2nsP+tupkJoEW4Qtm0xCaNeGUE8NFme+ hzr8ZBiapkRbDCfQ6I+1BgK0axYtUcZEoPIgXurHwRkOZmRLT6PgGIzMgp0bLcqosDMNJlziZBCv Dh46IaOl+7NB1ZmhD2xneXInD0zu5ebpuclaGM0TSAxd1BqyBhGgieza1ERc/90Q4EwKMFueCxfE Wi4EeeLFsH2zCeTppdAz7DLNqv5fRQFlvvf8vp+1WKBnE1982ZuGk7g/xA/OVaj+VASYU/8zygAA AAAAAA== ------=_NextPart_000_005D_01CE6B52.C6C78D60-- From richard@shockey.us Mon Jun 17 09:12: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 7AE2321F9CBA for ; Mon, 17 Jun 2013 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.291, 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 0qB4QQvR5eEj for ; Mon, 17 Jun 2013 09:12:36 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id DD41221F9C9F for ; Mon, 17 Jun 2013 09:12:35 -0700 (PDT) Received: (qmail 28149 invoked by uid 0); 17 Jun 2013 16:12:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 17 Jun 2013 16:11:57 -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=XafKz+nv9tba8c0oeRoo5OeDKHXcc4sKUtfVURqN888=; b=eLxLsuwxfkfcWk0tkEgs3RrAngb7TMmhCmulrTrTHt51tpsE3vu6MYQ497LLIcjrud3ZAkyLcsYsVx2b21cnmS2tXZGdeZFGdDs4e4WD7c0woL5oReR13fCNyMneB8Zp; Received: from [72.66.111.124] (port=52496 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uoc28-0006Yk-F5; Mon, 17 Jun 2013 10:11:56 -0600 From: "Richard Shockey" To: , "'Peterson, Jon'" References: <51BF2E12.8070209@dcrocker.net> In-Reply-To: <51BF2E12.8070209@dcrocker.net> Date: Mon, 17 Jun 2013 12:11:54 -0400 Message-ID: <012301ce6b75$63bcdb30$2b369190$@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: AQIgEBZoOg+Dnd5bjeekYN+dzFM5ugKIT7z4mIKFQQA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] current draft 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, 17 Jun 2013 16:12:41 -0000 >> This sounds like a transitive trust model based on trust amongst telcos. > > Not really. example.com gets to vouch for example.com addresses, and the Unlike email addresses, the relationship between the service provider and the user is not built into the identifier. What you've been describing is an unspecified service in the background that establishing this relationship. It's key because it authorizes the provider to vouch for use of the number. [RS> ] Dave this is a very good point which creates part of the complication here. There is a very specific relationship between service provider and the number that traditional Internet naming and addressing abstracts. The number is Owned by the nation state. Though the delegation process is different for each there are some exceptions such as the wholesale numbering markets where a provider sells blocks to an alternative service provider.. Skype, Google Voice, WhatsApp etc. Even in those cases the number is traditionally tied to the wholesale service provisioning by the originating provider. This situation created issues around who has access to national numbering resources that has caused endless regulatory disputes. If you are bored sometime you can do a search on FCC and Vonage .. From richard@shockey.us Mon Jun 17 09:46: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 B256F21F9BF3 for ; Mon, 17 Jun 2013 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.992 X-Spam-Level: X-Spam-Status: No, score=-101.992 tagged_above=-999 required=5 tests=[AWL=0.273, 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 a2sLm-qFfd3i for ; Mon, 17 Jun 2013 09:45:58 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id C40B221F9BCD for ; Mon, 17 Jun 2013 09:45:57 -0700 (PDT) Received: (qmail 30001 invoked by uid 0); 17 Jun 2013 16:45:21 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 17 Jun 2013 16:45:21 -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=T87t4p3IC6s4FyQNLBDApnM+Ygj9+VtOP/LL7VMCSp4=; b=GDfP2ZM4epMcxhdOaHDNbyXXbaQ9ko14FVn3g66wehUsFQYGx1E/SG0SOgec1o0H9mn71WBNRT5X8Q7yey/RK9GtoOoZLTmyeQiXZJAOHkRjDQlAHqA85QnLAMIjV86Y; Received: from [72.66.111.124] (port=52736 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UocYS-0001pq-Lv; Mon, 17 Jun 2013 10:45:21 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> Date: Mon, 17 Jun 2013 12:45:19 -0400 Message-ID: <013f01ce6b7a$0e555aa0$2b000fe0$@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: AQIeS+24DslSvLnJ8MI5p8Gz+jn+agINK/5mAay8OkgCxR4wsZhmYbTA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] current draft 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, 17 Jun 2013 16:46:02 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, June 17, 2013 12:04 PM To: hgs@cs.columbia.edu; hadriel.kaplan@oracle.com Cc: stir@ietf.org; dcrocker@bbiw.net; jon.peterson@neustar.biz Subject: Re: [stir] current draft charter All, I am following the thread and trying to grasp the heart of the matter. First point: This is about E.164 number delegation and proof of ownership. So, I find much of the discussion that seems to rely on DNS structure or Domain name structuring to be a distraction. How you prove proof of ownership of a domain is a separate, albeit twin problem. But, I think that is out of scope. I do not believe the answer here is to ask my evil twin if he owns the E.164. Second point: The delegation of E.164 numbers down the tree inextricable defines who owns the number, so any collection of certs into an authoritative repository MUST follow the same path back up, or you lose sight of that ownership. E.164 is already the hierarchy, so no second hierarchy is needed. The recipient of a number block or an individual number may need to receive the private key, else the carrier signs and inserts the signature on the path out from that user. (Note, still need to determine how many bytes constitute the signature such that it fits into an existing SS7 parameter. Perhaps the answer is to include an indicator in SS7 that the gateway to SIP must perform the signature outbound. But, that may limit this to a single hop, else need to trust follow-on SS7 networks to sign properly, but that may be acceptable.) Third point: The called party needs to unequivocally know how to validate an assertion and who to go to for the inputs to perform that validation. The how should be defined by the RFC, but the who ultimately depends on the root of each E.164 country code (see point 2). If the DNS is involved, I think that there is an IAB draft/RFC that says the DNS should not be used for all things. [RS> ] I was waiting for that little subject to come up. :-) Personally I detest this draft since it was clearly designed as an anti 6116 statement. Ive never liked it and personally I hope it is never published. Title : Architectural Considerations on Application Features in the DNS Author(s) : Jon Peterson Olaf Kolkman Hannes Tschofenig Bernard Aboba Filename : draft-iab-dns-applications-07.txt Pages : 37 Date : 2013-02-25 Abstract: A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some for example transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-iab-dns-applications There's also a htmlized version available at: http://tools.ietf.org/html/draft-iab-dns-applications-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-iab-dns-applications-07 So, it is likely that the called party search would start with a well-known URI to the CC authority, communication to which could be secure, who could then point to one or more authoritative services, depending on how the out-sourcing is done, who have the official cert associated with the official delegation of E.164 number blocks or numbers. This seems to be a parallel to the number portability databases, except that one is now looking for a cert rather than a route to the serving carrier. I am not suggesting that the NP databases be used, as this could be orthogonal to that. Doing a search based on using the E.164 as an index should not be an issue, since in many cases a 10k block of numbers may point to a single cert. RS> I wish to point out that reliance on 10K block delegations in most cases is essentially a nonstarter for endless reasons in the US and is irrelevant in other national jurisdictions. In those cases where portability occurs and single numbers have a different cert, the database could have an indicator of which 10k blocks require full E.164 search to be performed. (For international, blocks are defined by how many leading digits are used.) Fourth point: Lastly, so the called party has all the elements from the signaling with which to validate the signature, the RFC needs to specify what elements are prohibited from changing end-to-end. Given that some of the existing parameters do change in current systems, I don't know how you get around doing one of the following: - define new header that contains complete signature package that is added by whomever does the signing. - re-define existing headers to add the signature and restrict any intermediary from modifying those values. Seeing that the existing already have usage baggage, the first option seems more likely to succeed. Also, need to ensure that the SS7 network can carry elements E2E without changes. SS7 terminations may have to rely on the SIP-to-SS7 GW to perform validation. SIP terminations may have to rely on the SS7-to-SIP GW to generate signatures. SIP-SS7-SIP would be an issue given the "no change SS7" limitation. Did I miss any requirements or constraints here? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 17, 2013 8:14 AM To: Hadriel Kaplan Cc: stir@ietf.org; dcrocker@bbiw.net; Peterson, Jon Subject: Re: [stir] current draft charter I wouldn't be surprised if the large carriers cache all certs locally. For +1, I'd suggest that's less than a TB, i.e., a single disk, even if +every number has their own cert, rather than number ranges. They would then subscribe to a notification service for any porting-related changes, given that such changes affect a very small fraction of the numbers (quarterly churn of mobile carriers is about 1-2%). This can all be done within the carrier network, i.e., without affecting the external public data interface. On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote: > > On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" > wrote: > >> The exact amount of tolerable delay is a very interesting dimension >> of this problem space. I suspect we have a considerable amount of >> time, given all the human expectations about both post-dial delay and >> the wait for someone to pick up after altering. I think it's enough >> time to perform some non-trivial operations. > > I've been thinking about that and I'm not sure we actually have much time. I've been looking at what the CNAM guys are doing, and at least one them (used in a large mobile provider) goes so far as to sometimes skip it on the INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the delay. I.e., they have us queue the INVITE while they retrieve the CNAM info for the given caller-id, but if they take too long then we send the INVITE and send their results separately afterwards in another message. Another operator that uses private ENUM for CNAM querying also sets very low timeouts on the query, and just don't provide a calling name if it times out (ie., the INVITE gets sent on without it, and nothing updates it later). > > Also, Brian at one point mentioned transit providers possibly doing > the verification check as well, and that might be difficult if it > takes non-trivial time I think, because one of the SLA measurements > they get ranked on is how fast they route their calls onward. > (Besides which they're never involved this type of stuff so I'd doubt > they'd start now anyway.) > > Anecdotally, I find that intra-nation calls get to ringing stage much faster than international calls, so people are probably ok with international caller-id verification taking longer. > > -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 dhc@dcrocker.net Mon Jun 17 09:57: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 0F37421F9D61 for ; Mon, 17 Jun 2013 09:57:43 -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 EmojRQBMa0XK for ; Mon, 17 Jun 2013 09:57:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71BAF21F9D6D for ; Mon, 17 Jun 2013 09:57:21 -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 r5HGvH7M022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jun 2013 09:57:20 -0700 Message-ID: <51BF3FE0.2010103@dcrocker.net> Date: Mon, 17 Jun 2013 09:57:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Shockey References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> In-Reply-To: <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> 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, 17 Jun 2013 09:57:20 -0700 (PDT) Cc: stir@ietf.org, 'Michael Hammer' Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 16:57:46 -0000 On 6/17/2013 9:45 AM, Richard Shockey wrote: > [RS> ] I was waiting for that little subject to come up.:-) Personally I > detest this draft since it was clearly designed as an anti 6116 statement. > Ive never liked it and personally I hope it is never published. > > Title : Architectural Considerations on Application Features in > the DNS > Author(s) : Jon Peterson > Olaf Kolkman > Hannes Tschofenig > Bernard Aboba > Filename : draft-iab-dns-applications-07.txt yup: Review: draft-iab-dns-applications-07 http://www.ietf.org/mail-archive/web/ietf/current/msg77934.html and its two predecessors for earlier versions of the draft: http://trac.tools.ietf.org/group/iab/trac/ticket/35 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Mon Jun 17 09:59: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 87E8521F9D7A for ; Mon, 17 Jun 2013 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 0FACSY9as2ls for ; Mon, 17 Jun 2013 09:59:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F32AC21F9D79 for ; Mon, 17 Jun 2013 09:58:59 -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 r5HGwiM0032611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 16:58:45 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 r5HGwkX1001470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 16:58:46 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 r5HGwjoe015342; Mon, 17 Jun 2013 16:58:45 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 09:58:45 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> Date: Mon, 17 Jun 2013 12:58:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DE5EBA2-1033-4348-B9CC-2521698941AD@oracle.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] current draft 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, 17 Jun 2013 16:59:19 -0000 On Jun 17, 2013, at 12:04 PM, Michael Hammer = wrote: > First point: This is about E.164 number delegation and proof of = ownership. > So, I find much of the discussion that seems to rely on DNS structure = or > Domain name structuring to be a distraction. > How you prove proof of ownership of a domain is a separate, albeit = twin > problem. > But, I think that is out of scope. I do not believe the answer here = is to > ask my evil twin if he owns the E.164. There've been a bunch of emails so you've probably missed it, or maybe = it wasn't made clear, but the idea behind the DNS proposal is to use = reverse-number dotted notation for the E.164. So an E.164 of = '+16035551212' becomes the domain name '2.1.2.1.5.5.5.3.0.6.1.cid.arpa'. The authority for .cid.arpa is the ITU, and they delegate the = country-codes within it to the national number admins for each country = (ie, exactly what they do for E.164 numbers). At that point each nation = decides what they want to do, whether to have their whole country-code = number tree under one admin authority, or to have it split up. Oh, and this would all use DNSSEC, which might mean we don't even need = to store full certs in this tree, but can just store public keys. = (because the DNSSEC info is the same as would be in the certs) > Second point: The delegation of E.164 numbers down the tree = inextricable > defines who owns the number,=20 > so any collection of certs into an authoritative repository MUST = follow the > same path back up, or you lose sight of that ownership. > E.164 is already the hierarchy, so no second hierarchy is needed. Right, and the DNS proposal follows the E.164 ownership hierarchy. > The recipient of a number block or an individual number may need to = receive > the private key,=20 > else the carrier signs and inserts the signature on the path out from = that > user. No, the recipient of the number block creates their own private/public = key pair, and upload the public key to the DNS admin for their E.164 = number. In the DNS it gets signed by the number authority. So the = number authority (ie the DNS) never knows the private key - only the = actual user of the private key does. > (Note, still need to determine how many bytes constitute the signature = such > that it fits into an existing SS7 parameter. > Perhaps the answer is to include an indicator in SS7 that the gateway = to SIP > must perform the signature outbound. > But, that may limit this to a single hop, else need to trust follow-on = SS7 > networks to sign properly, but that may be acceptable.) If we can use a SS7 param, I believe the Identity signature can fit - if = I'm doing my math right, it's 128 bytes binary (or 172 bytes if base64 = encoded ascii). You'd need to include some other info as well to make this work, but I'm = pretty sure we could fit it all in the 255 bytes of an ISUP param. = Unless we have to include a URL, in which case all bets are off. -hadriel From dhc@dcrocker.net Sun Jun 16 17: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 4E20E21F9DD5 for ; Sun, 16 Jun 2013 17:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 s07LaHRuSlVS for ; Sun, 16 Jun 2013 17:48:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B07B21F9DD3 for ; Sun, 16 Jun 2013 17:48: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 r5H0m5lH026735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jun 2013 17:48:08 -0700 Message-ID: <51BE5CB8.8040801@dcrocker.net> Date: Sun, 16 Jun 2013 17:47:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 16 Jun 2013 17:48:09 -0700 (PDT) X-Mailman-Approved-At: Mon, 17 Jun 2013 10:00:06 -0700 Cc: "stir@ietf.org" , Hadriel Kaplan , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 00:48:16 -0000 On 6/16/2013 4:27 PM, Peterson, Jon wrote: >>> If I understand the RFC 4474 model correctly, a validated Identity >>> field has the semantics of asserting that the From field is valid. So >>> the assertion is not limited to the owner of the From field value. >>> Correct? While such a model is understandable, it dramatically >>> increases the reputation-management complexity of the task. I'm not >>> aware of an extant service over the public Internet of similar >>> complexity. > > We weren't exactly proposing a domain assurance council or something like DAC merely worked on a standardized query mechanism; it was not a service. But as far as defining a reputation-reporting service, actually you are. You are defining the ability of a third-party to vouch for a caller-id value that is not (necessarily) their own. That's different from defining a mechanism that let's someone assert direct ownership. > that. The authorization decision was supposed to be checking the reference > integrity of the domain in the From header field against the domain in the > subjectAltName of the cert (provided the cert is valid and the root > trusted): if there's a match, then this was signed for by the right That seems to be the first reference to the specific field in the cert, and assigning specific semantics to it. Any chance this is part of an existing spec relating to STIR? In any event, note that a premise of the model you've been describing is that the guy being validated gets to tell you where to look for the validation. That seems an odd trust model. I'd normally expect the verifying agent to choose the server with validation information separately. > entity, if not, then not. I'm not sure what you mean by "not limited to > the owner of the From field value." In so far as the originating domain is > the "owner," then only they can sign it, if that's the limitation you're > concerned about. That's not what RFC 4474 specifies, according to my reading of it: Section 4: The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to assert the identity that is populated in the From header field. "authorized to assert" does not have the same semantics as "is the owner of". Section 5, Step 2: The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the identity field. ditto. What you've defined permits multiple, separate third-parties to be able to make validity assertions about the use of the caller-id value. > Correct. The entity making the assertion tells the verifier where a cert > can be fetched, in the case that the verifier doesn't already have a cert > for the signer. Whether the cert is valid, or the CA itself is trusted by > the verifier, is however a different and prior question. When I ask someone for money, I think it's really nice that I get to tell them who to talk to, to vouch for my credit-worthiness... > Right. At the risk of waxing philosophical about it, I'd say that RFC4474 > took for granted the baseline assumption that RFC3263 would be how SIP > requests were routed. The idea that an authorization-checking mechanism would somehow depend upon the SIP routing service doesn't make obvious sense to me. Consequently I do not see how it should/can/will affect choice of the validation query service. >> So one proposal so far is that there would be certs which identify the >> E.164 numbers they're authoritative for (in a CN/SAN field for example), >> and that cert would be signed by some CA (or chain leading to one) that >> you trust. If it's a chain rather than directly signed by a CA, then >> it's not clear how one goes about retrieving the certs for the chain's >> links, and doing so could cause unacceptable delay. It also means we >> need revocation checks for the chain. And I'd argue the management >> aspects for this thing would be just as difficult as anything else >> proposed so far. > > Although I'm not the expert, my understanding is that there are various > cert chain compression techniques that could be applicable here. I've > squinted a bit at OCSP and other possible real-time revocation checks for > this as well. The essential point behind this line of discussion is that an entirely new cert semantic and trust structure will need to be invented and deployed. Note that this must be globally integrated and openly accessible. > But I do agree that there's no such thing as a free lunch, and that > implementing a credential system for telephone numbers, even just in a > single nation state, is operationally complex. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Jun 17 10:10: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 DFAE721F99AC for ; Mon, 17 Jun 2013 10:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 4D8kwbEcF9Am for ; Mon, 17 Jun 2013 10:10:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0A21F9AE8 for ; Mon, 17 Jun 2013 10:10:37 -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 r5HHANxN022935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jun 2013 10:10:27 -0700 Message-ID: <51BF42F2.7090507@dcrocker.net> Date: Mon, 17 Jun 2013 10:10:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <6DE5EBA2-1033-4348-B9CC-2521698941AD@oracle.com> In-Reply-To: <6DE5EBA2-1033-4348-B9CC-2521698941AD@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 17 Jun 2013 10:10:27 -0700 (PDT) Cc: "stir@ietf.org" , Michael Hammer , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: [stir] Nature vs. nurture -- semantics vs. encoding (was: Re: current draft 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: Mon, 17 Jun 2013 17:10:47 -0000 On 6/17/2013 9:58 AM, Hadriel Kaplan wrote: > > On Jun 17, 2013, at 12:04 PM, Michael Hammer wrote: > >> First point: This is about E.164 number delegation and proof of ownership. >> So, I find much of the discussion that seems to rely on DNS structure or >> Domain name structuring to be a distraction. >> How you prove proof of ownership of a domain is a separate, albeit twin >> problem. >> But, I think that is out of scope. I do not believe the answer here is to >> ask my evil twin if he owns the E.164. > > > There've been a bunch of emails so you've probably missed it, or maybe it wasn't made clear, but the idea behind the DNS proposal is to use reverse-number dotted notation for the E.164. So an E.164 of '+16035551212' becomes the domain name '2.1.2.1.5.5.5.3.0.6.1.cid.arpa'. The authorization-checking topic that is driving this list needs to distinguish between the basic semantics of what is being done -- who are the actors, what are their roles and authorities, what are their interactions -- from the low-level mechanics -- such as syntactic encoding form -- that are used to permit the 'interesting' stuff. One thing that seems to be a continuing distraction is "pure" E.164 number vs. domain name. As discussed in this venue, to domain name form is a syntactic encoding. On its own, it's no more interesting or terrible than any other encoding form. It makes sense to consider here only to the extent that the operational platform using it makes sense. The significant parts of determining whether a platform makes sense to consider are the many aspects of its operational details, ranging from beneficial history -- deployed and well-used -- to its administrative alignment with what is needed. > The authority for .cid.arpa is the ITU, and they delegate the country-codes within it to the national number admins for each country (ie, exactly what they do for E.164 numbers). At that point each nation decides what they want to do, whether to have their whole country-code number tree under one admin authority, or to have it split up. > > Oh, and this would all use DNSSEC, which might mean we don't even need to store full certs in this tree, but can just store public keys. (because the DNSSEC info is the same as would be in the certs) Or possibly not. DNSSec is still only partially deployed, and the use being discussed here is probably a re-purposing of its functionality. My own guess is that DNSSec makes sense for providing an important enhancement to reassurances about the operational platform, but that it's not essential to the core semantics. But of course, that's just my opinion... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From york@isoc.org Mon Jun 17 10:27: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 93A8021F9D86 for ; Mon, 17 Jun 2013 10:27:16 -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 yn5N2RHUrhBx for ; Mon, 17 Jun 2013 10:27:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD1C21F9D33 for ; Mon, 17 Jun 2013 10:27:11 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 17 Jun 2013 17:27:01 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Mon, 17 Jun 2013 17:27:00 +0000 From: Dan York To: Hadriel Kaplan , "Peterson, Jon" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KAgABTd4CAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp3gIAAEOyAgABhe4CAAHK1AIAAd7eA Date: Mon, 17 Jun 2013 17:27:00 +0000 Message-ID: In-Reply-To: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@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-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB072; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <93C2A0EBED59364CBE5A6A769F211973@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 17 Jun 2013 17:27:18 -0000 On 6/17/13 2:18 AM, "Hadriel Kaplan" wrote: >On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" >wrote: > >> The exact amount of tolerable delay is a very interesting dimension of >> this problem space. I suspect we have a considerable amount of time, >>given >> all the human expectations about both post-dial delay and the wait for >> someone to pick up after altering. I think it's enough time to perform >> some non-trivial operations. > >I've been thinking about that and I'm not sure we actually have much >time.=20 +1. As we as a society move more systems from the PSTN over to "IP communications" I suspect that we will see a growing expectation to have connections occur more quickly. Other factors may enter in here, too, in feeding that expectation. For instance, we may see WebRTC apps that quickly connect a calling user with another endpoint, and users may grow to expect that kind of quick connection. Or there may be a new IP-based telco that attempts to differentiate itself by providing the fastest connection time. Or there may be a major vendor that launches a campaign for IP communications like Google's "Speed Up The Web" that is aimed at providing quicker connections. I think you are right, Jon, based on *current* human expectations, but I could easily see those expectations changing and I think we need to be careful about tying a solution to current expectations. (Or at least if we do that needs to be a conscious choice.) >Anecdotally, I find that intra-nation calls get to ringing stage much >faster than international calls, so people are probably ok with >international caller-id verification taking longer. Agreed, based again on *current* expectations around user behavior. On the other hand, when I make a call using Skype or Facetime I expect the call to connect quickly. With some other apps browser-based apps I expect to be able to pretty much push the button to initiate a call and start talking. I think we need to plan for the success of communication moving over to IP and reaping some of the benefits of IP, including no longer being shackled to legacy PSTN behavior. My 2 cents, Dan From michael.hammer@yaanatech.com Mon Jun 17 10:31: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 D1C6E21F998A for ; Mon, 17 Jun 2013 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 CbKoBEbUMxKt for ; Mon, 17 Jun 2013 10:31:55 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 256A321F8825 for ; Mon, 17 Jun 2013 10:31:47 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 10:31:46 -0700 From: Michael Hammer To: "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdCAAIsegP//l1vA Date: Mon, 17 Jun 2013 17:31:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DD6BF@ex2k10mb2.corp.yaanatech.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> In-Reply-To: <013f01ce6b7a$0e555aa0$2b000fe0$@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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0288_01CE6B5F.028FB280" MIME-Version: 1.0 Subject: Re: [stir] current draft 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, 17 Jun 2013 17:32:00 -0000 ------=_NextPart_000_0288_01CE6B5F.028FB280 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit My point was that the mere fact of being in DNS did not convey any trustability. So, not objecting to DNS being used to find authoritative servers, just that it itself is not authoritative. Mike -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Monday, June 17, 2013 12:45 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] current draft charter -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Monday, June 17, 2013 12:04 PM To: hgs@cs.columbia.edu; hadriel.kaplan@oracle.com Cc: stir@ietf.org; dcrocker@bbiw.net; jon.peterson@neustar.biz Subject: Re: [stir] current draft charter All, I am following the thread and trying to grasp the heart of the matter. First point: This is about E.164 number delegation and proof of ownership. So, I find much of the discussion that seems to rely on DNS structure or Domain name structuring to be a distraction. How you prove proof of ownership of a domain is a separate, albeit twin problem. But, I think that is out of scope. I do not believe the answer here is to ask my evil twin if he owns the E.164. Second point: The delegation of E.164 numbers down the tree inextricable defines who owns the number, so any collection of certs into an authoritative repository MUST follow the same path back up, or you lose sight of that ownership. E.164 is already the hierarchy, so no second hierarchy is needed. The recipient of a number block or an individual number may need to receive the private key, else the carrier signs and inserts the signature on the path out from that user. (Note, still need to determine how many bytes constitute the signature such that it fits into an existing SS7 parameter. Perhaps the answer is to include an indicator in SS7 that the gateway to SIP must perform the signature outbound. But, that may limit this to a single hop, else need to trust follow-on SS7 networks to sign properly, but that may be acceptable.) Third point: The called party needs to unequivocally know how to validate an assertion and who to go to for the inputs to perform that validation. The how should be defined by the RFC, but the who ultimately depends on the root of each E.164 country code (see point 2). If the DNS is involved, I think that there is an IAB draft/RFC that says the DNS should not be used for all things. [RS> ] I was waiting for that little subject to come up. :-) Personally I detest this draft since it was clearly designed as an anti 6116 statement. Ive never liked it and personally I hope it is never published. Title : Architectural Considerations on Application Features in the DNS Author(s) : Jon Peterson Olaf Kolkman Hannes Tschofenig Bernard Aboba Filename : draft-iab-dns-applications-07.txt Pages : 37 Date : 2013-02-25 Abstract: A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some for example transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-iab-dns-applications There's also a htmlized version available at: http://tools.ietf.org/html/draft-iab-dns-applications-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-iab-dns-applications-07 So, it is likely that the called party search would start with a well-known URI to the CC authority, communication to which could be secure, who could then point to one or more authoritative services, depending on how the out-sourcing is done, who have the official cert associated with the official delegation of E.164 number blocks or numbers. This seems to be a parallel to the number portability databases, except that one is now looking for a cert rather than a route to the serving carrier. I am not suggesting that the NP databases be used, as this could be orthogonal to that. Doing a search based on using the E.164 as an index should not be an issue, since in many cases a 10k block of numbers may point to a single cert. RS> I wish to point out that reliance on 10K block delegations in most RS> cases is essentially a nonstarter for endless reasons in the US and is irrelevant in other national jurisdictions. In those cases where portability occurs and single numbers have a different cert, the database could have an indicator of which 10k blocks require full E.164 search to be performed. (For international, blocks are defined by how many leading digits are used.) Fourth point: Lastly, so the called party has all the elements from the signaling with which to validate the signature, the RFC needs to specify what elements are prohibited from changing end-to-end. Given that some of the existing parameters do change in current systems, I don't know how you get around doing one of the following: - define new header that contains complete signature package that is added by whomever does the signing. - re-define existing headers to add the signature and restrict any intermediary from modifying those values. Seeing that the existing already have usage baggage, the first option seems more likely to succeed. Also, need to ensure that the SS7 network can carry elements E2E without changes. SS7 terminations may have to rely on the SIP-to-SS7 GW to perform validation. SIP terminations may have to rely on the SS7-to-SIP GW to generate signatures. SIP-SS7-SIP would be an issue given the "no change SS7" limitation. Did I miss any requirements or constraints here? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 17, 2013 8:14 AM To: Hadriel Kaplan Cc: stir@ietf.org; dcrocker@bbiw.net; Peterson, Jon Subject: Re: [stir] current draft charter I wouldn't be surprised if the large carriers cache all certs locally. For +1, I'd suggest that's less than a TB, i.e., a single disk, even if +every number has their own cert, rather than number ranges. They would then subscribe to a notification service for any porting-related changes, given that such changes affect a very small fraction of the numbers (quarterly churn of mobile carriers is about 1-2%). This can all be done within the carrier network, i.e., without affecting the external public data interface. On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote: > > On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" > wrote: > >> The exact amount of tolerable delay is a very interesting dimension >> of this problem space. I suspect we have a considerable amount of >> time, given all the human expectations about both post-dial delay and >> the wait for someone to pick up after altering. I think it's enough >> time to perform some non-trivial operations. > > I've been thinking about that and I'm not sure we actually have much time. I've been looking at what the CNAM guys are doing, and at least one them (used in a large mobile provider) goes so far as to sometimes skip it on the INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the delay. I.e., they have us queue the INVITE while they retrieve the CNAM info for the given caller-id, but if they take too long then we send the INVITE and send their results separately afterwards in another message. Another operator that uses private ENUM for CNAM querying also sets very low timeouts on the query, and just don't provide a calling name if it times out (ie., the INVITE gets sent on without it, and nothing updates it later). > > Also, Brian at one point mentioned transit providers possibly doing > the verification check as well, and that might be difficult if it > takes non-trivial time I think, because one of the SLA measurements > they get ranked on is how fast they route their calls onward. > (Besides which they're never involved this type of stuff so I'd doubt > they'd start now anyway.) > > Anecdotally, I find that intra-nation calls get to ringing stage much faster than international calls, so people are probably ok with international caller-id verification taking longer. > > -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_0288_01CE6B5F.028FB280 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE3MzE0NFowIwYJKoZIhvcNAQkEMRYEFCrsjuSsPklH6zthLVz4PyA5zDGTMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAJnUWhmvVDutFzgaPYjFxsIeC39gUNZLIn45hyo0L 3SImU/3PkmOxpV63Iva5y+N1HqPKzkdDcTd9r69MCZe+bha9CwwyvmkF8iVu0XbGN5jzo8VFqixB OWurhz3bj+AdTVUjVPv4YW68vyBFo+3slfSJu8pigBbeaMyQPetJKw9z1Xee7c2uaMtkzhr1W+/F IQfuKUecLpQ/KaHFy6N7w0bu60zcFi899YR3NegpBpbRGB3x85qq7y1ZaitkyODtjQ+/opiWiwew VsP2SLqwC8IyC6Dcl7haEqYtK0eZNWqYTDsRE2U/eAOVeErTBWz7V+UMEm6WkhE0FLDNc881OQAA AAAAAA== ------=_NextPart_000_0288_01CE6B5F.028FB280-- From hadriel.kaplan@oracle.com Mon Jun 17 10:37: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 65C0C21F9A79 for ; Mon, 17 Jun 2013 10:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 dyXv6dPKmb2T for ; Mon, 17 Jun 2013 10:37:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DDE7121F9A6D for ; Mon, 17 Jun 2013 10:37:43 -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 r5HHbXxd011579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 17:37:33 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 r5HHbZqI002684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 17:37:35 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HHbYLM020975; Mon, 17 Jun 2013 17:37:34 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 10:37:34 -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, 17 Jun 2013 13:37:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 17:37:50 -0000 On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" = wrote: > I think the advantages below, with the exception of 4, would be true = of > any golden root we created for whatever protocol, be it HTTP or = something > else. I'm sure I could define an HTTP golden root such that the > verification service could synthesize the proper fetch request from = the > URI in the =46rom with an Identity-Info, one that updated in real time = so > you never needed to worry about revocation, one for which there was = only > one CA, and which you could locally cache (well, okay, 5 does conflict = a > bit with 2). Sure, there's no debate one could replicate the DNS protocol and = architecture to use HTTP as the accessing protocol instead of DNS = query/response. I have no idea why one would want to make a simple = database query protocol heavier for no benefit gain, but sure it's = possible. :) > Also, all of the (snipped) concerns you raised about access control, > middlemen, charging, etc are just as likely to arise for DNS as for = any > other proposal. No, they're not. For the middlemen issue, middlemen are of course also = possible using a DNS approach (they already exist today), but the = protocol used for the client to access the middleman would be = well-specified, because it's exactly the same as that used for cases = where there is no middleman: DNS. With regards to the access control and charging, the important point is = DNS would make it virtually impossible to *have* an access control and = charging model for queries. The protocol's characteristics actually = make it practically impossible to do. Country-A couldn't charge = Country-B to access the calling cert info for Country-A; and Carrier-A = couldn't charge Carrier-B to access the calling cert info for Carrier-A. = Instead, Country-A would incur the cost for managing their own E.164 = entries in DNS, and likewise Country-B pays for Country-B's numbers; or = Carrier-A would incur the cost for their E.164 numbers, and likewise = Carrier-B. I know that's a controversial position. It means deciding, up front, = that the only supportable pricing model for this thing in the grand = scale would be the same as for DNS domain names: charging only for = adding/managing entries in the database, not charging _other_ entities = per-query of the database. I think (but don't know) that this would = actually make this thing easier to get adoption for. At least in my = simple naive view, it might help international adoption if the decisions = each country makes are only technical and logistic for their own = country, rather than involve money between countries. [Note: this doesn't mean NPAC can't be used for this database in the = NANP, even though NPAC is a closed model and charged for query access I = think.] -hadriel From york@isoc.org Mon Jun 17 10:38: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 244B621F9C06 for ; Mon, 17 Jun 2013 10:38:25 -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 nsXPOPZ5vQIE for ; Mon, 17 Jun 2013 10:38:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id D963721F9BA9 for ; Mon, 17 Jun 2013 10:38:19 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 17 Jun 2013 17:38:16 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Mon, 17 Jun 2013 17:38:16 +0000 From: Dan York To: Michael Hammer , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: Not just "called party" - Re: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KAgABTd4CAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp3gIAAEOyAgABhe4CAAHK1AIAAY2yAgABAOYD//9c5AA== Date: Mon, 17 Jun 2013 17:38:16 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.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-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB072; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <03EDEAC76BEFDC43A504762E8EB50B07@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" Subject: [stir] Not just "called party" - Re: current draft 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, 17 Jun 2013 17:38:25 -0000 On 6/17/13 12:04 PM, "Michael Hammer" wrote: >Third point: The called party needs to unequivocally know how to validate >an assertion and who to go to for the inputs to perform that validation. I would not necessarily restrict it to the "called party". This is the dominant use case we've been discussing, I.e that I receive a call and want to be as certain as possible about the identity of the endpoint calling me. However, I could be calling out to my customers or clients and as the "calling party" would like to be as certain as possible that I am reaching the correct endpoint. Consider a bank wanting to reach a customer about issues with the customer's account - or to verify a recent transaction. Or a doctor's office want to relay results to a patient and wanting to be sure they are reaching the patient's number. My understanding is that we are aiming to solve the "secure origin identification" challenge - and that could apply to either or both ends of the conversation. Dan From hadriel.kaplan@oracle.com Mon Jun 17 10:43: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 B558721F9D93 for ; Mon, 17 Jun 2013 10:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 mqQo8PfaYsP4 for ; Mon, 17 Jun 2013 10:43:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3088F21F9D8B for ; Mon, 17 Jun 2013 10:43:52 -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 r5HHho0E004631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 17:43:51 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 r5HHhnXU028410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 17:43:50 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 r5HHhnoh008122; Mon, 17 Jun 2013 17:43:49 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 10:43:48 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD6BF@ex2k10mb2.corp.yaanatech.com> Date: Mon, 17 Jun 2013 13:43:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D6E85D6-A6BE-470A-A01D-570DF851B6A6@oracle.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3A03DD6BF@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "richard@shockey.us" Subject: Re: [stir] current draft 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, 17 Jun 2013 17:43:58 -0000 On Jun 17, 2013, at 1:31 PM, Michael Hammer = wrote: > My point was that the mere fact of being in DNS did not convey any > trustability. > So, not objecting to DNS being used to find authoritative servers, = just that > it itself is not authoritative. Just to be clear I've been using the term "DNS", but actually meaning it = with DNSSEC. If the country-code level domains are under the authority = of the national numbering plan admins for each country, then with DNSSEC = they'd be the ones signing the resource record entries in their DNS = tree. I can't imagine who could be more authoritative for a country's = E.164 numbers than the national number plan admin. They're certainly = more authoritative than existing certificate CAs, for example. :) -hadriel From jon.peterson@neustar.biz Mon Jun 17 10:46: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 1134121F9A05 for ; Mon, 17 Jun 2013 10:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 eeQbDyb9pK1A for ; Mon, 17 Jun 2013 10:46:12 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B045F21F96D9 for ; Mon, 17 Jun 2013 10:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371491660; x=1686847582; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=++0I3abzo/ QJttbz9133KDBf9HJ5uxfHwJNy51nr4oc=; b=aWMvqmN5WiWxv6YndQVcxYJoQK MzRBLJ+5Y+laGuIjBSlJlnoxb9xfd8R2GoiUl+W8kP3IWyvYGQ0hdB+/3nhw== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26399235; Mon, 17 Jun 2013 13:54:19 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 13:46:02 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAIv1AP//m/SAgACzSID//6H7gAAhAhkAAApO2IA= Date: Mon, 17 Jun 2013 17:46:01 +0000 Message-ID: In-Reply-To: <51BF2E12.8070209@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 716fMK9Le17BH3+HPcRflw== Content-Type: text/plain; charset="us-ascii" Content-ID: <8FE9E56F213003449E5FABBDAA25D00C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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, 17 Jun 2013 17:46:16 -0000 There are some more specific replies inline, but first this: Upleveling, there are a set of problems out there in the world that are caused by impersonation of calling numbers, and we have a choice here to try to address them or not. The STIR proposal does make the foundational assumption that we would have more leverage on the impersonation problem if Internet devices could somehow rely on the authority structures over numbering that are defined in the PSTN. I've tried here not to be overly prescriptive about what the best way is to project those authority structures onto the Internet. Certainly we could just decide at the get-go "it's certificates, there'll be a CA, based on existing CAs used by the numbering databases." Personally I'd rather hear more discussion about the alternatives under consideration, like putting credentials in the DNS. However, willingness to explore alternatives and understand the design space is not hand-waving, it's not sweeping things under the rug, it's not believing in unspecified miracles. Certificate authorities and the DNS are both fairly well understood commodities. The operational and deployment characteristics of these services are not particularly mysterious. If these are the possibilities under consideration, then I don't think we're in unfamiliar waters. We can examine these possibilities, and ultimately if appropriate we can allow either or both, in rfc447bis and the related specifications. Once we have the protocol machinery in place, maybe letting industry and regulators build out structures until we see what works would be instructive. As the PSTN transitions further onto the Internet in the coming years, there are going to have to be systems in place for authority, for routing, and so on that help bring telephone numbers onto the Internet. We don't have all the answers today about what that world will look like. All we can do is to move the ball forward, based on what we know today and what is achievable today, and the challenges we face in this transitional and transitioning system (like robocalling, vishing, swatting, etc). In order to do this, we need to fix things like RFC4474 so that it has hooks for supporting telephone numbers. That is the work in the proposed scope of STIR. On 6/17/13 8:41 AM, "Dave Crocker" wrote: >On 6/16/2013 11:56 PM, Peterson, Jon wrote: >>> As I understand it, this model of thousands of trust anchors is showing >>> some very rough edges for scaling, accuracy, and scope. I believe it >>> also has had a single semantic, unrelated to the one being proposed. >> >> Right, the rough edges there are why the current problem statement for >> STIR suggests we do things a bit differently. > >In looking over the draft charter that you circulated last Tuesday, I'm >not seeing text that obviously covers this. In contrast, all of the >list discussion about CAs appears to be based on the current model that >uses very large numbers of anchors. Obviously charters are at a low level of detail, as opposed to the input documents, but if this is enough of a hot-button issue to warrant a mention in the charter, I wouldn't oppose it. And as for the list discussion, well, we're all still coming to understand the problem space. I don't think I've heard people arguing that a very large number of overlapping trust anchors would be a wise way to start off. >Even with text in the charter, the deeper question is what changes are >feasible to the current model that are viable with the scale, diversity >and reliability needed for the proposed service? Absent a vetted design >approach, it won't mean much to have a charter task covering it; in fact >it will be more appropriate as an IRTF task... I think you need to be able to modularize in design to get anywhere. What is actually in the scope of the proposed charter are a set of narrow and achievable deliverables (at least for the first prong). It is not in the scope of the charter to design that "proposed service," any more than it is in the scope of the TLS working group to design web PKI. The TLS work doesn't have to operationally prove out web PKI in order to get a charter, and well, if it did, there are enough operational problems with web PKI that some might argue TLS should never be chartered. However, SSL/TLS have done a ton of good. Various efforts in the IETF and the industry at large are working to improve web PKI. If you'd like to form an IRTF working group to discuss the problems of scale, diversity and reliability of various credential systems, I won't stand in your way. The scope of this proposed working group is orthogonal to that. >>> I think I'm beginning to understand: The provider that is giving SIP >>> service is the one that vouches for its use. In effect, the provider >>> has the authority of the number owner, rather than the user to whom the >>> number is assigned. >... >>> That's not subtle; it's quite basic. It would be like requiring that >>>my >>> ISP be the one that vouches for my use of my domain name. >> >> If your ISP actually owned your domain name instead of you, sure. If in >> fact you own your own domain name, RFC4474 lets you (as in, your UA) act >> as your authentication service. The authentication service is a logical >> function that can be instantiated by either the UA or an intermediary. >>Who >> should do it depends pretty much entirely on who owns the domain name. >> >> Do I own the email address "jon.peterson@neustar.biz"? No, Neustar owns >> it. > >Number portability changes this. The number does not belong to the >service provider. Again, I've just been trying to get us on the same page about what RFC4474 says - then we talk about what it should be amended to say about numbers (or rather, that's the scope of the proposed work here). You may know more about number portability than me, but I don't agree with your assessment of it here. At best, I'd say that number portability in America allows consumers to choose which carrier "owns" a number. This is also a reason I keep putting scare quotes around "owns," because the assumptions of the DNS don't apply to users of telephone numbers, at least not in our current regulatory environment. If you are a registrant, you have the authority to configure your zone - that sounds close enough to be ownership to me (even though the UDRP or ICE can end your ownership under extreme conditions). If you have a telephone number assigned to you, a carrier still decides what number it rings. >>> This sounds like a transitive trust model based on trust amongst >>>telcos. >> >> Not really. example.com gets to vouch for example.com addresses, and the > >Unlike email addresses, the relationship between the service provider >and the user is not built into the identifier. What you've been >describing is an unspecified service in the background that establishing >this relationship. It's key because it authorizes the provider to vouch >for use of the number. What I've been describing is the existing relationship between the service provider and the user. Agreed that a credential should be able to allow a service provider to vouch for the end user in some circumstances, just as the owner of "example.com" vouches for "jon@example.com." >>>> I'm not sure it's a new cert semantic, or a new trust structure, or >>>>that >>>> something needs to be "invented" to support this. >>> >>> Feel free to point to instances of each that are deployed and used. >> >> The structures that underly trust in the proposed STIR work are simply >>the >> extent ones in the telephone network. > >By way of considering edge cases, to the extent that this mechanism is >going to validate uses of numbers for calls that do not originate from >their home -- such as the mobile physician calling from someone else's >phone -- the extant trust mechanisms don't cover them. There are corner cases that are going to be challenging here that we won't know the right way to address out of the gate. "Legitimate spoofing" is one where I'm aware of a few possible approaches but I anyway don't yet know which one would be best. This would be something for the working group to examine.=20 =20 >In any event, the considerable barrier to adoption you've just described >is adoption by all telcos. I didn't just describe a system that requires adoption by all telcos, not in the sense you mean. In so far as all telcos are part of the PSTN where those structures are codified already in various databases and credentials, telcos are already part of a numbering authority system. For example, if you are a carrier in North America, you get number blocks from your national regulator and interface with databases that let you update routes or perform similar administrative tasks. You get various kinds of credentials, with various scopes of authority, to authenticate yourself to these systems. Incrementally, systems on the Internet could begin to depend on that authority, if it were projected onto the Internet in some fashion - like through a CA, for example. It would not require every telco to suddenly start using it for it to be useful. The STIR proposal also has a second approach (the fallback mechanism) that tries to build grass-roots, bottom credentials as well to cover more of the problem space. >> There are currently number block >> assignees, delegates of those assignees, and ultimately end users who >> possess numbers. Databases exist that contain all that information, and >> credentials exist that reflect those scopes of authority. The proposed >> work is only to leverage those structures. > >Forgive me but I don't see any of that in the charter or discussions so >far. It seems to be left as the "then a miracle happens" part of the >specification. As such, it isn't possible to evaluate its practicality. No, what's in the charter is the work that's in the scope of the IETF - things like fixing RFC4474 so it could contain assertions that cover telephone numbers.=20 The creation of a certificate with a telephone number inside which you fetch with a web get is not a miracle. It is possible to evaluate its practicality.=20 >On 6/17/2013 12:07 AM, Peterson, Jon wrote:> >> I think the advantages below, with the exception of 4, would be true >> of any golden root we created for whatever protocol, be it HTTP or >> something else. I'm sure I could define an HTTP golden root such that > >The real point of practical leverage here is existing deployment. It's >easy to 'define' almost anything. Getting deployment and adequate >operational service is the hard part. In the IETF, we define things. The world deploys and operates them. We need to define things in a way that make it possible that they can be deployed and operated, sure. >> the verification service could synthesize the proper fetch request >> from the URI in the From with an Identity-Info, one that updated in >> real time so you never needed to worry about revocation, one for > >For any existing capability, I'm sure one can define a new service that >contains it. The question is what risks and benefits come with that new >effort? HTTP is not a "new service." Its trade-offs are fairly well understood. Jon Peterson Neustar, Inc, > > >On 6/17/2013 5:03 AM, Henning Schulzrinne wrote: >> It might be helpful to explicitly distinguish three models, > > independent of whether the cert is stored in DNS or some HTTP-accessed > > data store: > >Big +1 for this sort of analytic discipline in the effort... > > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From michael.hammer@yaanatech.com Mon Jun 17 10:52: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 EE07C21F9D99 for ; Mon, 17 Jun 2013 10:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 tSBEqGscIRLV for ; Mon, 17 Jun 2013 10:52:48 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 418F621F9D88 for ; Mon, 17 Jun 2013 10:52:47 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 10:52:44 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdCAAI7dgP//lC9w Date: Mon, 17 Jun 2013 17:52:43 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DD74B@ex2k10mb2.corp.yaanatech.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <6DE5EBA2-1033-4348-B9CC-2521698941AD@oracle.com> In-Reply-To: <6DE5EBA2-1033-4348-B9CC-2521698941AD@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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0295_01CE6B61.EFF16EE0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] current draft 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, 17 Jun 2013 17:52:59 -0000 ------=_NextPart_000_0295_01CE6B61.EFF16EE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Inline... -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Monday, June 17, 2013 12:59 PM To: Michael Hammer Cc: hgs@cs.columbia.edu; stir@ietf.org; dcrocker@bbiw.net; jon.peterson@neustar.biz Subject: Re: [stir] current draft charter On Jun 17, 2013, at 12:04 PM, Michael Hammer wrote: > First point: This is about E.164 number delegation and proof of ownership. > So, I find much of the discussion that seems to rely on DNS structure > or Domain name structuring to be a distraction. > How you prove proof of ownership of a domain is a separate, albeit > twin problem. > But, I think that is out of scope. I do not believe the answer here > is to ask my evil twin if he owns the E.164. There've been a bunch of emails so you've probably missed it, or maybe it wasn't made clear, but the idea behind the DNS proposal is to use reverse-number dotted notation for the E.164. So an E.164 of '+16035551212' becomes the domain name '2.1.2.1.5.5.5.3.0.6.1.cid.arpa'. The authority for .cid.arpa is the ITU, and they delegate the country-codes within it to the national number admins for each country (ie, exactly what they do for E.164 numbers). At that point each nation decides what they want to do, whether to have their whole country-code number tree under one admin authority, or to have it split up. Oh, and this would all use DNSSEC, which might mean we don't even need to store full certs in this tree, but can just store public keys. (because the DNSSEC info is the same as would be in the certs) MH> I didn't miss any and saw the ENUM-style discussion. That is an inheritance. My point is that SPs were able to do number string analysis without the reverse tree building, so something more like a CIDR reading of an E.164 would be sufficient. I don't object to the above per se, but the key is who is allowed to populate that tree and how do you enforce that? I assume that the DNSSEC would need to do that. You would have to define how any delegation is enforced with DNSSEC. Also, explain how the called user (even on PTSN) is going know he is not being spoofed by DNS. > Second point: The delegation of E.164 numbers down the tree > inextricable defines who owns the number, so any collection of certs > into an authoritative repository MUST follow the same path back up, or > you lose sight of that ownership. > E.164 is already the hierarchy, so no second hierarchy is needed. Right, and the DNS proposal follows the E.164 ownership hierarchy. > The recipient of a number block or an individual number may need to > receive the private key, else the carrier signs and inserts the > signature on the path out from that user. No, the recipient of the number block creates their own private/public key pair, and upload the public key to the DNS admin for their E.164 number. In the DNS it gets signed by the number authority. So the number authority (ie the DNS) never knows the private key - only the actual user of the private key does. MH> Not worded so well apparently. Yes, I was implying that the individual number user would need to generate the key pair, or that the carrier could do that for them. Also, if the numbers were aggregated, i.e. blocks, the carrier could generate and report up the chain the key pair. So, we are saying the same thing. > (Note, still need to determine how many bytes constitute the signature > such that it fits into an existing SS7 parameter. > Perhaps the answer is to include an indicator in SS7 that the gateway > to SIP must perform the signature outbound. > But, that may limit this to a single hop, else need to trust follow-on > SS7 networks to sign properly, but that may be acceptable.) If we can use a SS7 param, I believe the Identity signature can fit - if I'm doing my math right, it's 128 bytes binary (or 172 bytes if base64 encoded ascii). You'd need to include some other info as well to make this work, but I'm pretty sure we could fit it all in the 255 bytes of an ISUP param. Unless we have to include a URL, in which case all bets are off. MH> Still waiting on the specifics of that. -hadriel ------=_NextPart_000_0295_01CE6B61.EFF16EE0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE3NTI0MlowIwYJKoZIhvcNAQkEMRYEFFo9IEvtvFFXdDMjyTNgm1UxQR9eMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANr4FyRMsIqYVBJBJXmXDkpptk099FqzB2NJI3qps np9609X38J7WxycCVMbQcK2XE3hPEG6A6J0QIzQ3PyB2aRys9cUIQZVk8WwzNL2P+4CwTWRC+BWc VPNn3yQxXLt56vhaoLpbqoDyZ+N04OO4yT7Oafw7BptKkHDNk7R1nSU02l5fxZ6Fun/M1P2NMEiI 5hCC3twl5cb34tV6pzSbwev8g2qed3IuM0guN9zX6utYddDE1RCbv4mpwwjizNy6YVmZ5RcE/Vlq sKYlYPOrdsVf8vPd6E/ZiHTMMIZ4LO1OmbJTldnIH3Z82qOuRbiG9YDrQLcY5f2FN1RO3/bpKwAA AAAAAA== ------=_NextPart_000_0295_01CE6B61.EFF16EE0-- From jon.peterson@neustar.biz Mon Jun 17 11: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 8A9B221F92E7 for ; Mon, 17 Jun 2013 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.246 X-Spam-Level: X-Spam-Status: No, score=-106.246 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 dQU5O7Ahuwjj for ; Mon, 17 Jun 2013 11:00:21 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A461C21F9CB9 for ; Mon, 17 Jun 2013 11:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371492504; x=1686847582; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=uxZRc9dCod Clz3Ucg1izSi6mVKLYudE7BMx3YPAldC0=; b=H6A7a8GTCPcmdTF6yYYvgmdt2f lo4AyM+/LFb4cEjytKyZBbFTuhUXIIXdY1YHZ27jqjehWYC9pn23T6+M/yYg== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26400061; Mon, 17 Jun 2013 14:08:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 14:00:03 -0400 From: "Peterson, Jon" To: Dan York , Hadriel Kaplan Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAOgKAIAAuskA//+T3wA= Date: Mon, 17 Jun 2013 18:00:03 +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.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: bKW2x0Ctf2k9KFhDKKPmHw== Content-Type: text/plain; charset="us-ascii" Content-ID: <3041438C67330949A1EB6C2DA3579E91@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 17 Jun 2013 18:00:30 -0000 I hear what you're saying, but I'd imagine there will always be a difference in time-frame between "speeding up the web" and waiting for a human to pick up a phone. Humans have to react to altering, get their phone out of a pocket, etc. Nothing about how much faster we make the web will reduce the distance (physical and psychological) between my pool and my phone charger when a call comes in. Now, what if we hope to make the phone never ring at all? The potential laziness of callees is meaningful because only the caller perceives the delay. Certainly we can play alerting back to the caller even if the callee phone is trying to resolve authorization. In fact, in many blocking circumstances, continuing to play alerting forever might be the right thing to do if the callee is declining the caller. Ultimately we are going to have to have some estimate of what the budget is here and match it against what we hope to accomplish. Jon Peterson Neustar, Inc. On 6/17/13 10:27 AM, "Dan York" wrote: >On 6/17/13 2:18 AM, "Hadriel Kaplan" wrote: > > >>On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" >>wrote: >> >>> The exact amount of tolerable delay is a very interesting dimension of >>> this problem space. I suspect we have a considerable amount of time, >>>given >>> all the human expectations about both post-dial delay and the wait for >>> someone to pick up after altering. I think it's enough time to perform >>> some non-trivial operations. >> >>I've been thinking about that and I'm not sure we actually have much >>time.=20 > >+1. As we as a society move more systems from the PSTN over to "IP >communications" I suspect that we will see a growing expectation to have >connections occur more quickly. Other factors may enter in here, too, in >feeding that expectation. For instance, we may see WebRTC apps that >quickly connect a calling user with another endpoint, and users may grow >to expect that kind of quick connection. Or there may be a new IP-based >telco that attempts to differentiate itself by providing the fastest >connection time. Or there may be a major vendor that launches a campaign >for IP communications like Google's "Speed Up The Web" that is aimed at >providing quicker connections. > >I think you are right, Jon, based on *current* human expectations, but I >could easily see those expectations changing and I think we need to be >careful about tying a solution to current expectations. (Or at least if we >do that needs to be a conscious choice.) > >>Anecdotally, I find that intra-nation calls get to ringing stage much >>faster than international calls, so people are probably ok with >>international caller-id verification taking longer. > >Agreed, based again on *current* expectations around user behavior. On >the other hand, when I make a call using Skype or Facetime I expect the >call to connect quickly. With some other apps browser-based apps I expect >to be able to pretty much push the button to initiate a call and start >talking. > >I think we need to plan for the success of communication moving over to IP >and reaping some of the benefits of IP, including no longer being shackled >to legacy PSTN behavior. > >My 2 cents, >Dan > From michael.hammer@yaanatech.com Mon Jun 17 11:01: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 D614221F92E7 for ; Mon, 17 Jun 2013 11:01:38 -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 N79eui32wILa for ; Mon, 17 Jun 2013 11:01: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 B654321F8FF3 for ; Mon, 17 Jun 2013 11:01:33 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 11:01:33 -0700 From: Michael Hammer To: "york@isoc.org" , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: Not just "called party" - Re: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdCAAJnqAP//kKFQ Date: Mon, 17 Jun 2013 18:01:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DD7CA@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_029E_01CE6B63.2B669300" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" Subject: Re: [stir] Not just "called party" - Re: current draft 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, 17 Jun 2013 18:01:39 -0000 ------=_NextPart_000_029E_01CE6B63.2B669300 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit By doing that you turn this from a source identity non-repudiation capability to a routing assurance capability (receipt non-repudiation). Despite being useful, I thought that was not in scope. Mike -----Original Message----- From: Dan York [mailto:york@isoc.org] Sent: Monday, June 17, 2013 1:38 PM To: Michael Hammer; hgs@cs.columbia.edu; hadriel.kaplan@oracle.com Cc: stir@ietf.org; dcrocker@bbiw.net; jon.peterson@neustar.biz Subject: Not just "called party" - Re: [stir] current draft charter On 6/17/13 12:04 PM, "Michael Hammer" wrote: >Third point: The called party needs to unequivocally know how to >validate an assertion and who to go to for the inputs to perform that validation. I would not necessarily restrict it to the "called party". This is the dominant use case we've been discussing, I.e that I receive a call and want to be as certain as possible about the identity of the endpoint calling me. However, I could be calling out to my customers or clients and as the "calling party" would like to be as certain as possible that I am reaching the correct endpoint. Consider a bank wanting to reach a customer about issues with the customer's account - or to verify a recent transaction. Or a doctor's office want to relay results to a patient and wanting to be sure they are reaching the patient's number. My understanding is that we are aiming to solve the "secure origin identification" challenge - and that could apply to either or both ends of the conversation. Dan ------=_NextPart_000_029E_01CE6B63.2B669300 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE4MDEzMVowIwYJKoZIhvcNAQkEMRYEFH9p52kirvSnxnAahmHTetTCvZe2MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAZwOLklv3rKvJVAwAHnufn14dTD5TPhascTllF3Oz 6BYUNwJ39IcZQR0Qfk3XQSLZCArwNAhU2DfFZCbOe2fFXwfaTtfhCmUwnz2hyQmZaPqNUPIm8G/L zFsRNeJ80W7UB9F/aYIY/jRtUM4itApqpa2rdLm773SMq5EcajleJKqEZhvbLcIB4HupLu7bTzVN sh6C4bAbm7NwPVrz2nyRUBBT/abcRmo4lY/1e94LjB7kjLueo7okYlRbR/jgi6I8FHu015APbM+W npigvJAEqj3kLK26m4lYb2GEa3f1/E7I0/6w0RJAHXfJ8dS3mElbWSlXKCln2Xye07dUULY0TgAA AAAAAA== ------=_NextPart_000_029E_01CE6B63.2B669300-- From richard@shockey.us Mon Jun 17 11:02: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 736BE21F9D39 for ; Mon, 17 Jun 2013 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=0.257, 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 5zPnze-nSqTM for ; Mon, 17 Jun 2013 11:02:40 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 312D521F962D for ; Mon, 17 Jun 2013 11:02:39 -0700 (PDT) Received: (qmail 22744 invoked by uid 0); 17 Jun 2013 18:02:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 17 Jun 2013 18:01:59 -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=+cZfHFjEoojoRk7X88oHZU8Box2FSk63sjkUjGGniDY=; b=GgRUoLdLeJlznfC8ByqfwYnSNEDq5tcmpw03jPMYaOKBaLFE5PP2LU6UvQPRtWVtQNzoFwVb/thl0YQTVLn9TT9qHoiX77kHvuYIbFLEI2RXdWWcnkL+FPlNQrnacXNT; Received: from [72.66.111.124] (port=53749 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uodkc-000323-GE; Mon, 17 Jun 2013 12:01:58 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Peterson, Jon'" References: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> In-Reply-To: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> Date: Mon, 17 Jun 2013 14:01:57 -0400 Message-ID: <018b01ce6b84$c2d72da0$488588e0$@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: AQGgKKOkSXmxa6YsgRhV8X1nuFoYbgFJ8UzhmYxminA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Henning Schulzrinne' Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 18:02:46 -0000 [Note: this doesn't mean NPAC can't be used for this database in the NANP, even though NPAC is a closed model and charged for query access I think.] [RS> ] [RS> ] Not since 2009. The NPAC like most national numbering databases are now operated on fixed price contracts. The days of transaction based or dip charges are long long gone. Cost recovery is usually based on the number of entries or TN's in the data base and an annual allocation model approved by the national regulator. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Mon Jun 17 11:03: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 3BB8D21F9DA3 for ; Mon, 17 Jun 2013 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 9h6ZZPr6iK5b for ; Mon, 17 Jun 2013 11:03:42 -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 0B1B521F9D39 for ; Mon, 17 Jun 2013 11:03:40 -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 d7f4fb15.5042b940.303498.00-526.858452.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Jun 2013 18:03:41 +0000 (UTC) X-MXL-Hash: 51bf4f7d5f3a914e-65187b31525d46c1511b8cbae367499564711b9b 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 87f4fb15.0.303460.00-254.858322.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Jun 2013 18:03:40 +0000 (UTC) X-MXL-Hash: 51bf4f7c4bedc429-40b719d1cd201ff6b864ee65144ab78ed7a7fa8e 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 r5HI3ZHP004117; Mon, 17 Jun 2013 14:03:36 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5HI3RcA003932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 14:03:28 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 17 Jun 2013 18:03:13 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 14:03:19 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" , Dan York , Hadriel Kaplan Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVPvBwdWSMpuU+7zbFbFufQ5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KAgABTd4CAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp3gIAAEOyAgABhe4CAAHK1AIAAd7eAgACPXID//72T0A== Date: Mon, 17 Jun 2013 18:03:18 +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.86.19] 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=EMyxJSlC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=CT05AzjYeewA:10 a=KIbchom90_cA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=UIkZVOpWgVUA:10 a=48vgC7mUAAAA:8 a=k7Ga1wGzAAAA:8] X-AnalysisOut: [ a=qerv6Y54AAAA:8 a=yPCof4ZbAAAA:8 a=hGBaWAWWAAAA:8 a=I61F] X-AnalysisOut: [lXWMwwx85pQ17rwA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=f] X-AnalysisOut: [cAx7uNQz4EA:10 a=7Zfzu0Ws3woA:10 a=7DSvI1NPTFQA:10 a=6_LLc] X-AnalysisOut: [mUAZMlMHFjh:21 a=1s_B65MeIC64edA2:21] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 17 Jun 2013 18:03:49 -0000 How is this n the scope of this charter, Jon...can we focus -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pet= erson, Jon Sent: Monday, June 17, 2013 2:00 PM To: Dan York; Hadriel Kaplan Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter I hear what you're saying, but I'd imagine there will always be a difference in time-frame between "speeding up the web" and waiting for a human to pick up a phone. Humans have to react to altering, get their phone out of a pocket, etc. Nothing about how much faster we make the web will reduce the distance (physical and psychological) between my pool and my phone charger when a call comes in. Now, what if we hope to make the phone never ring at all? The potential laziness of callees is meaningful because only the caller perceives the delay. Certainly we can play alerting back to the caller even if the callee phone is trying to resolve authorization. In fact, in many blocking circumstances, continuing to play alerting forever might be the right thing to do if the callee is declining the caller. Ultimately we are going to have to have some estimate of what the budget is here and match it against what we hope to accomplish. Jon Peterson Neustar, Inc. On 6/17/13 10:27 AM, "Dan York" wrote: >On 6/17/13 2:18 AM, "Hadriel Kaplan" wrote: > > >>On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" >>wrote: >> >>> The exact amount of tolerable delay is a very interesting dimension of >>> this problem space. I suspect we have a considerable amount of time, >>>given >>> all the human expectations about both post-dial delay and the wait for >>> someone to pick up after altering. I think it's enough time to perform >>> some non-trivial operations. >> >>I've been thinking about that and I'm not sure we actually have much >>time.=20 > >+1. As we as a society move more systems from the PSTN over to "IP >communications" I suspect that we will see a growing expectation to have >connections occur more quickly. Other factors may enter in here, too, in >feeding that expectation. For instance, we may see WebRTC apps that >quickly connect a calling user with another endpoint, and users may grow >to expect that kind of quick connection. Or there may be a new IP-based >telco that attempts to differentiate itself by providing the fastest >connection time. Or there may be a major vendor that launches a campaign >for IP communications like Google's "Speed Up The Web" that is aimed at >providing quicker connections. > >I think you are right, Jon, based on *current* human expectations, but I >could easily see those expectations changing and I think we need to be >careful about tying a solution to current expectations. (Or at least if we >do that needs to be a conscious choice.) > >>Anecdotally, I find that intra-nation calls get to ringing stage much >>faster than international calls, so people are probably ok with >>international caller-id verification taking longer. > >Agreed, based again on *current* expectations around user behavior. On >the other hand, when I make a call using Skype or Facetime I expect the >call to connect quickly. With some other apps browser-based apps I expect >to be able to pretty much push the button to initiate a call and start >talking. > >I think we need to plan for the success of communication moving over to IP >and reaping some of the benefits of IP, including no longer being shackled >to legacy PSTN behavior. > >My 2 cents, >Dan > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Mon Jun 17 11:05: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 16AF321F9A6A for ; Mon, 17 Jun 2013 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 B214sgqQEySn for ; Mon, 17 Jun 2013 11:05: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 8CFE121F9DC9 for ; Mon, 17 Jun 2013 11:05:01 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 11:05:01 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdCAAIsegP//l1vAgAB4+4D//4/xgA== Date: Mon, 17 Jun 2013 18:05:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DD801@ex2k10mb2.corp.yaanatech.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3A03DD6BF@ex2k10mb2.corp.yaanatech.com> <9D6E85D6-A6BE-470A-A01D-570DF851B6A6@oracle.com> In-Reply-To: <9D6E85D6-A6BE-470A-A01D-570DF851B6A6@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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02A3_01CE6B63.A74E8B80" MIME-Version: 1.0 Cc: "stir@ietf.org" , "richard@shockey.us" Subject: Re: [stir] current draft 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, 17 Jun 2013 18:05:46 -0000 ------=_NextPart_000_02A3_01CE6B63.A74E8B80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit That is a key distinction and ties into my assertion that the CC numbering authority must control that. But, clarify one thing for me. Does DNSSEC ensure both: - that the uploading of information is authentic, - attempts to read the data actually get to that secure entry? Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Monday, June 17, 2013 1:44 PM To: Michael Hammer Cc: richard@shockey.us; stir@ietf.org Subject: Re: [stir] current draft charter On Jun 17, 2013, at 1:31 PM, Michael Hammer wrote: > My point was that the mere fact of being in DNS did not convey any > trustability. > So, not objecting to DNS being used to find authoritative servers, > just that it itself is not authoritative. Just to be clear I've been using the term "DNS", but actually meaning it with DNSSEC. If the country-code level domains are under the authority of the national numbering plan admins for each country, then with DNSSEC they'd be the ones signing the resource record entries in their DNS tree. I can't imagine who could be more authoritative for a country's E.164 numbers than the national number plan admin. They're certainly more authoritative than existing certificate CAs, for example. :) -hadriel ------=_NextPart_000_02A3_01CE6B63.A74E8B80 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE4MDQ1OVowIwYJKoZIhvcNAQkEMRYEFM9iFNwgwtNb5K35DCwQJZGnMfcGMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOto6ugsd+EFKNFPQKQQKYPeEz35f1X608Dfsmm+L AItwt7X783g0RVnz5JlDu/r/4pAXXoBU9x36TYnWoTfLk2M/b7u1gkr9OriZV8aiEwwz5yq79J7C Z44uL+nQdDSaSXSo69tMexfIi06aXMyvabh+v5FJLDVrojuZhVz5vqC0F95mU/9JNR+9n1IuUWrS Gv/ZH5IVJUudrSub03YmjLpgfPsLei3LWEl3hGcE/i/ORgCUrXFeoLTIIu4u4wtsL+Z1uw2Ku0+n 4ZEjD3VM5uVJcCt5ez/pTPGG+KSpF9Za3yF0zrLAwVbsi0p2OtebfyGqkx63vTGCQWtoxXFl3AAA AAAAAA== ------=_NextPart_000_02A3_01CE6B63.A74E8B80-- From hadriel.kaplan@oracle.com Mon Jun 17 11:14: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 AC39A21F9D7E for ; Mon, 17 Jun 2013 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 g1y9vqRn85w2 for ; Mon, 17 Jun 2013 11:13:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E82321F9D5A for ; Mon, 17 Jun 2013 11:13:56 -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 r5HIDjC3020879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 18:13:46 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 r5HIDkQ8025281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 18:13:47 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 r5HIDk1D012572; Mon, 17 Jun 2013 18:13:46 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 11:13:46 -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: <018b01ce6b84$c2d72da0$488588e0$@shockey.us> Date: Mon, 17 Jun 2013 14:13:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4AFB94AF-03E0-4AF9-B04D-C45C99C06BBD@oracle.com> References: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> <018b01ce6b84$c2d72da0$488588e0$@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, "'Peterson, Jon'" , 'Henning Schulzrinne' Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 18:14:03 -0000 On Jun 17, 2013, at 2:01 PM, "Richard Shockey" = wrote: >=20 > [Note: this doesn't mean NPAC can't be used for this database in the = NANP, > even though NPAC is a closed model and charged for query access I = think.] > [RS> ]=20 >=20 > [RS> ] Not since 2009. The NPAC like most national numbering databases = are > now operated on fixed price contracts. The days of transaction based = or dip > charges are long long gone. Cost recovery is usually based on the = number of > entries or TN's in the data base and an annual allocation model = approved by > the national regulator.=20 Excellent. Then there's no problem on that front, either. :) -hadriel From dhc@dcrocker.net Mon Jun 17 11:28: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 7B76F21F9D86 for ; Mon, 17 Jun 2013 11:28:44 -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 3GCpCi1ZTkwW for ; Mon, 17 Jun 2013 11:28:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19521F9D82 for ; Mon, 17 Jun 2013 11:28:39 -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 r5HISZjL024611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jun 2013 11:28:39 -0700 Message-ID: <51BF5546.3090004@dcrocker.net> Date: Mon, 17 Jun 2013 11:28:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 17 Jun 2013 11:28:39 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft 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: Mon, 17 Jun 2013 18:28:44 -0000 On 6/17/2013 10:46 AM, Peterson, Jon wrote: > Personally I'd rather hear more discussion about the alternatives under > consideration, like putting credentials in the DNS. However, willingness > to explore alternatives and understand the design space is not > hand-waving, it's not sweeping things under the rug, it's not believing in > unspecified miracles. I have an even more extreme suggestion: Get some clarity and agreement on the services that are needed, independent of the way they might be implemented. That will permit evaluating alternative implementation approaches more systematically and equitably. The key to such an exercise is to make /non-technical/ statements about functionality. What are the semantics of the service? Who are the actors? What are their roles? What flexibilities in the service are desirable? All stated without reference to technologies. I find that such an exercise often helps avoid distracting debates about minor points and moves things to consensus about requirements that really are core. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Mon Jun 17 11:45: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 9F07821F92B8 for ; Mon, 17 Jun 2013 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.087, 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 GUsuCgSXK0VS for ; Mon, 17 Jun 2013 11:45:48 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCAC21F9285 for ; Mon, 17 Jun 2013 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371494686; x=1686853782; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=HKFO4abBpL iYzwdBlzBQCz9Kht3Sgr8K0FMac2b1gx4=; b=WmAxDmIg4vHsVF2j+AsVyFaPuC qtclzBBBJ7WZYzskPSQPnKCoyWvLh58Y64pdJHTytwp9tKko+RxoTcX1gPkw== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21072933; Mon, 17 Jun 2013 14:44:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 14:45:32 -0400 From: "Peterson, Jon" To: Michael Hammer , "york@isoc.org" , "hgs@cs.columbia.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: Not just "called party" - Re: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgIAAm7yAgAAQaYCAAADrAP//j/IAABs/tYAADWnTgAAZGt+A///GjoCABI/SgIAAEO2A///sJgCAAOgKAIAAY2yAgABAOYCAABpKAIAABoAA//+W7QA= Date: Mon, 17 Jun 2013 18:45:32 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD7CA@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: eVIIHkeMuxpfdSBlerLGhQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <0E4A9DDDCAD82C45B3A756EF20BE0AEE@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Not just "called party" - Re: current draft 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, 17 Jun 2013 18:45:52 -0000 I think it's a much harder problem, anyway, and I wouldn't want to put it on our plate until we've understood more about source identity. I imagine that there are alternative ways to approach the fallback mechanism that could probably confer this property for some use cases. Jon Peterson Neustar, Inc. On 6/17/13 11:01 AM, "Michael Hammer" wrote: >By doing that you turn this from a source identity non-repudiation >capability to=20 >a routing assurance capability (receipt non-repudiation). > >Despite being useful, I thought that was not in scope. > >Mike > > >-----Original Message----- >From: Dan York [mailto:york@isoc.org] >Sent: Monday, June 17, 2013 1:38 PM >To: Michael Hammer; hgs@cs.columbia.edu; hadriel.kaplan@oracle.com >Cc: stir@ietf.org; dcrocker@bbiw.net; jon.peterson@neustar.biz >Subject: Not just "called party" - Re: [stir] current draft charter > > >On 6/17/13 12:04 PM, "Michael Hammer" >wrote: > >>Third point: The called party needs to unequivocally know how to >>validate an assertion and who to go to for the inputs to perform that >validation. > >I would not necessarily restrict it to the "called party". This is the >dominant use case we've been discussing, I.e that I receive a call and >want >to be as certain as possible about the identity of the endpoint calling >me. > >However, I could be calling out to my customers or clients and as the >"calling party" would like to be as certain as possible that I am reaching >the correct endpoint. Consider a bank wanting to reach a customer about >issues with the customer's account - or to verify a recent transaction. >Or a >doctor's office want to relay results to a patient and wanting to be sure >they are reaching the patient's number. > >My understanding is that we are aiming to solve the "secure origin >identification" challenge - and that could apply to either or both ends of >the conversation. > >Dan > From hadriel.kaplan@oracle.com Mon Jun 17 11:57: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 0827421F9A86 for ; Mon, 17 Jun 2013 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 rCihvZyuzgYe for ; Mon, 17 Jun 2013 11:57:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7002321F9A74 for ; Mon, 17 Jun 2013 11:57:06 -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 r5HIv5ps016580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 18:57:05 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 r5HIv1n5012060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 18:57:04 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 r5HIv1s1022025; Mon, 17 Jun 2013 18:57:01 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 11:57:01 -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: <00C069FD01E0324C9FFCADF539701DB3A03DD801@ex2k10mb2.corp.yaanatech.com> Date: Mon, 17 Jun 2013 14:57:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> <013f01ce6b7a$0e555aa0$2b000fe0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3A03DD6BF@ex2k10mb2.corp.yaanatech.com> <9D6E85D6-A6BE-470A-A01D-570DF851B6A6@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD801@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "richard@shockey.us" Subject: Re: [stir] current draft 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, 17 Jun 2013 18:57:13 -0000 On Jun 17, 2013, at 2:05 PM, Michael Hammer = wrote: > That is a key distinction and ties into my assertion that the CC = numbering > authority must control that. >=20 > But, clarify one thing for me. Does DNSSEC ensure both: > - that the uploading of information is authentic, I am not-at-all an expert on DNSSEC, but I don't believe it covers how = the info gets uploaded into the DNS database. Of course neither does = anything else. Regardless of what protocol and architecture we end up using, at the end = of the day the administrator of a given database has to provision the = "customers" that can upload for which E.164 entries. Each customer = account is provisioned with some set of credentials with which to do so = - for example a username+password, or whatever. The customers then use = some mechanism to upload/update their entries with the credentials. = This could be through a web portal, or Dynamic DNS, or sending faxes. It would definitely be nice to provide a defined protocol means of doing = some of that, for at least the part of: customer-X which already has an = account with credentials in database Y, and is already assigned E.164 = number Z, being able to upload a public-key or unsigned cert for number = Z into the database Y. I don't really care what the protocol is for = that to happen, although defining something over HTTPS makes the most = sense to me for that. > - attempts to read the data actually get to that secure entry? If I understand it right, it doesn't actually matter if you reach the = right server or not - if another server responds with a false/fake = entry, you'll correctly detect it is fake; if another server responds = with a correct entry, you'll detect that it's not fake and it's = perfectly ok to use it. -hadriel From jon.peterson@neustar.biz Mon Jun 17 11:59: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 C2D9721F9A74 for ; Mon, 17 Jun 2013 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 X0hjhh7pzMKH for ; Mon, 17 Jun 2013 11:59:13 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A900C21F9A76 for ; Mon, 17 Jun 2013 11:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371495726; x=1686854417; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=5Df+AJLdOZ zp6YDjmJ0TOJRPndMA87TpO0r8vHALF+s=; b=mVpe5mrYf3LpbWFi2DDpyVSrsT AqXAgaE3kBWrYtq4vhPQjib+LKmCZKbk6GTV8fw9YvnnAkcRRL3pV9bFsjhw== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25241762; Mon, 17 Jun 2013 15:02:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 14:59:00 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKAgAElawD//6FkgA== Date: Mon, 17 Jun 2013 18:58:59 +0000 Message-ID: In-Reply-To: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: f1wsHdHF5Dkn1TXh9DCvgQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 18:59:16 -0000 I agree it would be great to find a technical approach to this that simplified business relationships, but I don't think we can depend on technical standards to restrain policy. That would be like stipulating that intermediaries can't change RFC3261 request bodies in order to - but never mind. It is ingenious to turn the inability to authenticate queries to the DNS into a virtue in this regard, but I'm still not sure I understand how this model would really prevent middlemen from charging if they wanted to, short of recreating e164.arpa as some comparable public golden root. Without it, there will always be ways that nation-states could restrict access to queries from outside their borders, say, unless they go through this for-pay VPN or what have you. Jon Peterson Neustar, Inc. On 6/17/13 10:37 AM, "Hadriel Kaplan" wrote: > >On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" >wrote: > >> I think the advantages below, with the exception of 4, would be true of >> any golden root we created for whatever protocol, be it HTTP or >>something >> else. I'm sure I could define an HTTP golden root such that the >> verification service could synthesize the proper fetch request from the >> URI in the From with an Identity-Info, one that updated in real time so >> you never needed to worry about revocation, one for which there was only >> one CA, and which you could locally cache (well, okay, 5 does conflict a >> bit with 2). > >Sure, there's no debate one could replicate the DNS protocol and >architecture to use HTTP as the accessing protocol instead of DNS >query/response. I have no idea why one would want to make a simple >database query protocol heavier for no benefit gain, but sure it's >possible. :) > > >> Also, all of the (snipped) concerns you raised about access control, >> middlemen, charging, etc are just as likely to arise for DNS as for any >> other proposal. > >No, they're not. For the middlemen issue, middlemen are of course also >possible using a DNS approach (they already exist today), but the >protocol used for the client to access the middleman would be >well-specified, because it's exactly the same as that used for cases >where there is no middleman: DNS. > >With regards to the access control and charging, the important point is >DNS would make it virtually impossible to *have* an access control and >charging model for queries. The protocol's characteristics actually make >it practically impossible to do. Country-A couldn't charge Country-B to >access the calling cert info for Country-A; and Carrier-A couldn't charge >Carrier-B to access the calling cert info for Carrier-A. Instead, >Country-A would incur the cost for managing their own E.164 entries in >DNS, and likewise Country-B pays for Country-B's numbers; or Carrier-A >would incur the cost for their E.164 numbers, and likewise Carrier-B. > >I know that's a controversial position. It means deciding, up front, >that the only supportable pricing model for this thing in the grand scale >would be the same as for DNS domain names: charging only for >adding/managing entries in the database, not charging _other_ entities >per-query of the database. I think (but don't know) that this would >actually make this thing easier to get adoption for. At least in my >simple naive view, it might help international adoption if the decisions >each country makes are only technical and logistic for their own country, >rather than involve money between countries. > >[Note: this doesn't mean NPAC can't be used for this database in the >NANP, even though NPAC is a closed model and charged for query access I >think.] > >-hadriel > From michael.hammer@yaanatech.com Mon Jun 17 12:03: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 78B5A21F9DE7 for ; Mon, 17 Jun 2013 12:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 JLNb40o3CF4C for ; Mon, 17 Jun 2013 12:03:34 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id D436821F99A5 for ; Mon, 17 Jun 2013 12:03:19 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 12:03:19 -0700 From: Michael Hammer To: "jon.peterson@neustar.biz" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxSZyaUX2cyBk2/ZGQqej7gqJk3mvQAgAG9DwCAAJEBgIAADb2AgACwEACAABbBgP//i2zA Date: Mon, 17 Jun 2013 19:03:18 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DDB98@ex2k10mb2.corp.yaanatech.com> References: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_031E_01CE6B6B.CC769800" MIME-Version: 1.0 Cc: "stir@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 19:03:38 -0000 ------=_NextPart_000_031E_01CE6B6B.CC769800 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I would suspect that if a called party attempt to fetch a cert and is told to pay, you will find users will just not accept the call. That could occur prior to ringing based on service provisioning. So, if countries don't want their calls to cross boundaries, that will do it. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, June 17, 2013 2:59 PM To: Hadriel Kaplan Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases I agree it would be great to find a technical approach to this that simplified business relationships, but I don't think we can depend on technical standards to restrain policy. That would be like stipulating that intermediaries can't change RFC3261 request bodies in order to - but never mind. It is ingenious to turn the inability to authenticate queries to the DNS into a virtue in this regard, but I'm still not sure I understand how this model would really prevent middlemen from charging if they wanted to, short of recreating e164.arpa as some comparable public golden root. Without it, there will always be ways that nation-states could restrict access to queries from outside their borders, say, unless they go through this for-pay VPN or what have you. Jon Peterson Neustar, Inc. On 6/17/13 10:37 AM, "Hadriel Kaplan" wrote: > >On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" >wrote: > >> I think the advantages below, with the exception of 4, would be true >>of any golden root we created for whatever protocol, be it HTTP or >>something else. I'm sure I could define an HTTP golden root such that >>the verification service could synthesize the proper fetch request >>from the URI in the From with an Identity-Info, one that updated in >>real time so you never needed to worry about revocation, one for >>which there was only one CA, and which you could locally cache (well, >>okay, 5 does conflict a bit with 2). > >Sure, there's no debate one could replicate the DNS protocol and >architecture to use HTTP as the accessing protocol instead of DNS >query/response. I have no idea why one would want to make a simple >database query protocol heavier for no benefit gain, but sure it's >possible. :) > > >> Also, all of the (snipped) concerns you raised about access control, >> middlemen, charging, etc are just as likely to arise for DNS as for >> any other proposal. > >No, they're not. For the middlemen issue, middlemen are of course also >possible using a DNS approach (they already exist today), but the >protocol used for the client to access the middleman would be >well-specified, because it's exactly the same as that used for cases >where there is no middleman: DNS. > >With regards to the access control and charging, the important point is >DNS would make it virtually impossible to *have* an access control and >charging model for queries. The protocol's characteristics actually >make it practically impossible to do. Country-A couldn't charge >Country-B to access the calling cert info for Country-A; and Carrier-A >couldn't charge Carrier-B to access the calling cert info for >Carrier-A. Instead, Country-A would incur the cost for managing their >own E.164 entries in DNS, and likewise Country-B pays for Country-B's >numbers; or Carrier-A would incur the cost for their E.164 numbers, and likewise Carrier-B. > >I know that's a controversial position. It means deciding, up front, >that the only supportable pricing model for this thing in the grand >scale would be the same as for DNS domain names: charging only for >adding/managing entries in the database, not charging _other_ entities >per-query of the database. I think (but don't know) that this would >actually make this thing easier to get adoption for. At least in my >simple naive view, it might help international adoption if the >decisions each country makes are only technical and logistic for their >own country, rather than involve money between countries. > >[Note: this doesn't mean NPAC can't be used for this database in the >NANP, even though NPAC is a closed model and charged for query access I >think.] > >-hadriel > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_031E_01CE6B6B.CC769800 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzE5MDMxN1owIwYJKoZIhvcNAQkEMRYEFNSApXkYZH7R9LYw1hO488Q8Q0qYMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAKUA5qSmIqAKq5JFkbufhrJHBcARZmWv5p6Vp0Zu3 sL5qTZaENyDp9j6/xnSKhQBEKiar5nEjq2ezI5DdwPZ+kxFzKJqS9wg354uDzc7qCGuIrSuY0zib AEO8hBWA7rhWJ2BNbLZ8SNtFRIjyLz/wSgS34RA2d1a59gAGcKbjPjICXbRlbOnEYgZ6/TwNsRVR MaN6uE+unV8ra9xdVB3DDNFPQxWpF25C1789zjMG/bc4/VjDLJobHfc3LiCY6bQ5DJ2Kj8DZrMnX XJqb4G9YlGdic1POqTeiaS/68bup4OmPguCkEZBGgVaYeMARv7drMBnGd0Zd/mKRJSolSfdgWQAA AAAAAA== ------=_NextPart_000_031E_01CE6B6B.CC769800-- From hadriel.kaplan@oracle.com Mon Jun 17 12:05: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 5EAA821F9A76 for ; Mon, 17 Jun 2013 12:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 Es6b-Izs-Knn for ; Mon, 17 Jun 2013 12:05:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39A21F99A5 for ; Mon, 17 Jun 2013 12:05:11 -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 r5HJ4ufF011842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 19:04:57 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 r5HJ4vIB029940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 19:04:58 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HJ4vT3011887; Mon, 17 Jun 2013 19:04:57 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 12:04:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 17 Jun 2013 15:04:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <453B19AF-088C-4859-8BEB-D5437B32456B@oracle.com> References: To: Dan York X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Michael Hammer , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] Not just "called party" - Re: current draft 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, 17 Jun 2013 19:05:19 -0000 For sake of focus and having a prayer of getting this done before we all = retire, I think we should focus exclusively on caller-id reputability. = No bank would ever trust this type of thing for called-party identity = anyway, because it only identifies phone numbers not humans - i.e., at = best it identifies a phone, not the person on the other end. Thus = they'll have to ask you a bunch of identifying questions anyway. -hadriel On Jun 17, 2013, at 1:38 PM, Dan York wrote: > I would not necessarily restrict it to the "called party". This is = the > dominant use case we've been discussing, I.e that I receive a call and > want to be as certain as possible about the identity of the endpoint > calling me. >=20 > However, I could be calling out to my customers or clients and as the > "calling party" would like to be as certain as possible that I am = reaching > the correct endpoint. Consider a bank wanting to reach a customer = about > issues with the customer's account - or to verify a recent = transaction. Or > a doctor's office want to relay results to a patient and wanting to be > sure they are reaching the patient's number. >=20 > My understanding is that we are aiming to solve the "secure origin > identification" challenge - and that could apply to either or both = ends of > the conversation. >=20 > Dan >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From york@isoc.org Mon Jun 17 12:55: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 9B2EA21F940D for ; Mon, 17 Jun 2013 12:55:46 -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 WNIePbUs5PD7 for ; Mon, 17 Jun 2013 12:55:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30721F9E00 for ; Mon, 17 Jun 2013 12:55:18 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB071.namprd06.prod.outlook.com (10.242.211.15) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 17 Jun 2013 19:55:14 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Mon, 17 Jun 2013 19:55:14 +0000 From: Dan York To: Michael Hammer , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxT0wAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AP//41KAgABTd4CAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp3gIAAEOyAgABhe4CAAHK1AIAAY2yAgABAOYCAAAt/gIAADPmAgAADXICAAAXuAP//27kA Date: Mon, 17 Jun 2013 19:55:13 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DD801@ex2k10mb2.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-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB071; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , "richard@shockey.us" Subject: Re: [stir] current draft 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, 17 Jun 2013 19:55:46 -0000 Mike, On 6/17/13 2:05 PM, "Michael Hammer" wrote: >But, clarify one thing for me. Does DNSSEC ensure both: >- that the uploading of information is authentic, DNSSEC ensures that the information the recipient is retrieving from DNS is the same information that was put into DNS by the entity operating the DNS servers for that domain (and signing the records). It provides an integrity check on the data received in a DNS query. It can make no assertions about the quality or authenticity of the data that was uploaded into the DNS servers. All it can say is that the data you are receiving matches the data that was served by the DNS servers (based on the cryptographic signatures). If an attacker compromised the DNS servers, including the ability to generate DNSSEC signatures, he or she would be able to upload bogus data - but if this happens there are probably larger issues for the operator of the servers to worry about. In the STIR example, if we were to use DNS we would need to assume a certain level of trust in the entities putting the phone numbers and corresponding identities into the DNS. As you mentioned this is probably the CC numbering authority in many/most cases. >- attempts to read the data actually get to that secure entry? DNSSEC has a concept of a "global chain of trust" that links the individual records and their signatures up to an ultimate trust anchor, which, in the case of public DNSSEC would be the root of the DNS. Essentially, you have a DNSKEY record with your public key. There is then a Delegation Signer (DS) record in the parent zone that is a hash of the DNSKEY[1]. This continues on up to the TLDs and to the root. If STIR were to use DNS/DNSSEC, the entity (server, IP-PBX, SBC, endpoint, whatever) performing the DNSSEC validation for the call would know that it was reaching the secure entry because: 1. the info for the telephone number identifier (cert, text record, whatever) would be cryptographically signed by the zone's public key (carried in the matching RRSIG record). 2. the entity would be able to use the DS records to walk back up the global chain of trust to be sure that it was using the correct key for validation. If either of these cases failed (a bad (or nonexistent) signature or an inability to verify the chain of trust), the entity performing validation would know that it had probably NOT been able to get to that secure entry. Note that this assumes that DNSSEC would *always* be used so that a nonexistent signature would also cause a warning. Dan [1] And yes, I'm simplifying this a bit for the purpose of illustration. Those who want more gory details can see RFC 6781 - http://tools.ietf.org/html/rfc6781 -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ From michael.hammer@yaanatech.com Mon Jun 17 13:15: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 54D5A21F9476 for ; Mon, 17 Jun 2013 13:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 nUhpezKnkTJH for ; Mon, 17 Jun 2013 13:15:34 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE121F938E for ; Mon, 17 Jun 2013 13:15:34 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 17 Jun 2013 13:15:34 -0700 From: Michael Hammer To: "york@isoc.org" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAAHK0AIAAY22A///AmdCAAIsegP//l1vAgAB4+4D//4/xgAASmQ6AAA4e9lA= Date: Mon, 17 Jun 2013 20:15:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DDD4A@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3A03DD801@ex2k10mb2.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.180] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0469_01CE6B75.E3F2D110" MIME-Version: 1.0 Cc: "stir@ietf.org" , "richard@shockey.us" Subject: Re: [stir] current draft 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, 17 Jun 2013 20:15:38 -0000 ------=_NextPart_000_0469_01CE6B75.E3F2D110 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks for that clarification. The crux still seems to be the linking of a domain node to an E.164 delegation node point. So, DNSSEC would require ENUM style domain structure to some level. Note, that will lead to the usual root wars. Possible, but likely need to get everyone on the same tree. Mike -----Original Message----- From: Dan York [mailto:york@isoc.org] Sent: Monday, June 17, 2013 3:55 PM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org; richard@shockey.us Subject: Re: [stir] current draft charter Mike, On 6/17/13 2:05 PM, "Michael Hammer" wrote: >But, clarify one thing for me. Does DNSSEC ensure both: >- that the uploading of information is authentic, DNSSEC ensures that the information the recipient is retrieving from DNS is the same information that was put into DNS by the entity operating the DNS servers for that domain (and signing the records). It provides an integrity check on the data received in a DNS query. It can make no assertions about the quality or authenticity of the data that was uploaded into the DNS servers. All it can say is that the data you are receiving matches the data that was served by the DNS servers (based on the cryptographic signatures). If an attacker compromised the DNS servers, including the ability to generate DNSSEC signatures, he or she would be able to upload bogus data - but if this happens there are probably larger issues for the operator of the servers to worry about. In the STIR example, if we were to use DNS we would need to assume a certain level of trust in the entities putting the phone numbers and corresponding identities into the DNS. As you mentioned this is probably the CC numbering authority in many/most cases. >- attempts to read the data actually get to that secure entry? DNSSEC has a concept of a "global chain of trust" that links the individual records and their signatures up to an ultimate trust anchor, which, in the case of public DNSSEC would be the root of the DNS. Essentially, you have a DNSKEY record with your public key. There is then a Delegation Signer (DS) record in the parent zone that is a hash of the DNSKEY[1]. This continues on up to the TLDs and to the root. If STIR were to use DNS/DNSSEC, the entity (server, IP-PBX, SBC, endpoint, whatever) performing the DNSSEC validation for the call would know that it was reaching the secure entry because: 1. the info for the telephone number identifier (cert, text record, whatever) would be cryptographically signed by the zone's public key (carried in the matching RRSIG record). 2. the entity would be able to use the DS records to walk back up the global chain of trust to be sure that it was using the correct key for validation. If either of these cases failed (a bad (or nonexistent) signature or an inability to verify the chain of trust), the entity performing validation would know that it had probably NOT been able to get to that secure entry. Note that this assumes that DNSSEC would *always* be used so that a nonexistent signature would also cause a warning. Dan [1] And yes, I'm simplifying this a bit for the purpose of illustration. Those who want more gory details can see RFC 6781 - http://tools.ietf.org/html/rfc6781 -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ------=_NextPart_000_0469_01CE6B75.E3F2D110 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx NzIwMTUzMlowIwYJKoZIhvcNAQkEMRYEFBHZSCoobn+9h0NdtEkvACKtzXdqMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAM/Tj1E86g0jE9N4YBAjL5YCWt1xSmjouShmBR72p 2iaLs1TtOITvTmtYGi2QLiR3vJqp3j+x5TGCK/kC3JBIrl+a+Pphns/dWDFXOwsobCQEp9sWE6cD Eb9uyuA45qAe2EFsnBkY6wKArL3r6dQuvyFBP6OChyauh1kTOQ7HlhyA82gTYjc+on3qQ2+zdGt4 WhJcEqR1WBv767I8S3FSKqPf/x10P/aWovymFkylRRQnb14le3T6C1lMZGy0fSONUWlug01sshZj sYKtLjYX3pA53RxjhSP9Og4UGEW1C4Xq54URLguwKQKnFNWPqY893ERE0T6GD4IqPVK/iGmIWwAA AAAAAA== ------=_NextPart_000_0469_01CE6B75.E3F2D110-- From pkyzivat@alum.mit.edu Mon Jun 17 13:18: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 0F70B21F9D63 for ; Mon, 17 Jun 2013 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi4sKTWNc5yK for ; Mon, 17 Jun 2013 13:18:31 -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 11CB121F9D48 for ; Mon, 17 Jun 2013 13:18:30 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id pY6y1l0070EZKEL59YJWCb; Mon, 17 Jun 2013 20:18:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id pYJV1l01X3ZTu2S3MYJVuS; Mon, 17 Jun 2013 20:18:30 +0000 Message-ID: <51BF6F15.3030906@alum.mit.edu> Date: Mon, 17 Jun 2013 16:18:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <51BF2E12.8070209@dcrocker.net> In-Reply-To: <51BF2E12.8070209@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371500310; bh=Ie2+lEC90xag2ars6DIhtQXKKYFaqowX8aWaF+mSh2Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S8rvNjD+BRZhvEhVLgRmc8/pcuDMsakmfjSqfivjtjbMQC4dlvAPuDDoYu8364PVk S0p4uaY1rk6yBV3/PGnGZ8hL7OrAwEbgFmTLh+J+G1+19VPemHPm4fEEeu7CUjXPuB 9knRiIqQEoSV8S59/DJJNbFmZDzKJsU+7MKOjmeCavrt4FZ7P36m8+hb0pSp0nJMLF zMKsQl47EyD+Qh/aXvsnzyMFEc+MfAAp0kHk7M6I94FiCgFqx5xDEB1Uqya/kQuce7 T09hbZ3S5xcFrqzod0t7PH4uX9Qa5twO6BmPAmKo3zrQuotAme7kQ7YVyCxGxqoZ3j y0NAwIYP9Ocjw== Subject: Re: [stir] current draft 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, 17 Jun 2013 20:18:37 -0000 On 6/17/13 11:41 AM, Dave Crocker wrote: >> Do I own the email address "jon.peterson@neustar.biz"? No, Neustar owns >> it. > > Number portability changes this. The number does not belong to the > service provider. Number portability doesn't apply to URIs like "sip:"jon.peterson@neustar.biz". (I have no expectation that I can port sip:pkyzivat@cisco.com to pkyzivat@alum.mit.edu.) Number portability pertains to telephone numbers. The reality that we paste telephone numbers onto domain names to form SIP URIs confuses the issue. In general doing so in no way implies that the domain has any responsibility for or ownership of the phone number. If we always used tel URIs for phone numbers then this would be clearer, though no easier to solve. Thanks, Paul From richard@shockey.us Mon Jun 17 13:26: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 9B0CA21F9D24 for ; Mon, 17 Jun 2013 13:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.722 X-Spam-Level: X-Spam-Status: No, score=-100.722 tagged_above=-999 required=5 tests=[AWL=-1.058, 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 nVXEBKV8rQ2T for ; Mon, 17 Jun 2013 13:26:37 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 2BB0E21F9D11 for ; Mon, 17 Jun 2013 13:26:37 -0700 (PDT) Received: (qmail 23365 invoked by uid 0); 17 Jun 2013 20:26:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 17 Jun 2013 20:26:03 -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=ciS0/xgJGHmwvhDI7ZfFzfZh6ZI7SUsG6vYJOAUZWR0=; b=RiapSJpdoiAGmIsD3Nxof5lCbCBttA3Tgazx4G6hr/CXt/31QZ4RVtTISzAwSMuWzCVCZMLI1EfpbPm2MwlptzGpzcX78PQBF2TH3k11jECU4IW4htGikxQ84Fx3RhBp; Received: from [72.66.111.124] (port=55737 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uog03-0005D9-La for stir@ietf.org; Mon, 17 Jun 2013 14:26:03 -0600 From: "Richard Shockey" To: Date: Mon, 17 Jun 2013 16:26:02 -0400 Message-ID: <024201ce6b98$e3bbcda0$ab3368e0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0243_01CE6B77.5CAA2DA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac5rmOJp+ddECcfARlqQVfyNZCfFwg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: [stir] Just out of curiosity .. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 20:26:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0243_01CE6B77.5CAA2DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Considering the timing has a decision been made on BOF vs DISPATCH? 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 ------=_NextPart_000_0243_01CE6B77.5CAA2DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Considering the timing has a decision been made on BOF = vs DISPATCH?

 

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

 

------=_NextPart_000_0243_01CE6B77.5CAA2DA0-- From york@isoc.org Mon Jun 17 13:30: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 0149021F9702 for ; Mon, 17 Jun 2013 13:30:46 -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 n-XIDC36EAUJ for ; Mon, 17 Jun 2013 13:30:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0921F96EB for ; Mon, 17 Jun 2013 13:30:36 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB069.namprd06.prod.outlook.com (10.242.211.11) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 17 Jun 2013 20:30:29 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Mon, 17 Jun 2013 20:30:29 +0000 From: Dan York To: Hadriel Kaplan Thread-Topic: [stir] Not just "called party" - Re: current draft charter Thread-Index: AQHOa42aQgZvEdck+kOC1OHCyL3cgpk6GNgA Date: Mon, 17 Jun 2013 20:30:29 +0000 Message-ID: In-Reply-To: <453B19AF-088C-4859-8BEB-D5437B32456B@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-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB069; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , Michael Hammer , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] Not just "called party" - Re: current draft 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, 17 Jun 2013 20:30:46 -0000 Hadriel, On 6/17/13 3:04 PM, "Hadriel Kaplan" wrote: >For sake of focus and having a prayer of getting this done before we all >retire,=20 Ack! We need something deployable - and sooner rather than later. I definitely agree with that. >I think we should focus exclusively on caller-id reputability. No bank >would ever trust this type of thing for called-party identity anyway, >because it only identifies phone numbers not humans - i.e., at best it >identifies a phone, not the person on the other end. Thus they'll have >to ask you a bunch of identifying questions anyway. Yes, using a bank as an example was a poor choice on my part because they do have many other processes for identifying the person they are calling. In this era of call automation, though, being able to have better confidence in the identifier of the number being called would be advantageous and could feed application calling logic. If an outbound application called a number and received as the secure identifier the number/identifier it had on file, the application could deliver whatever message it had. If there was a mismatch, the app could deliver a different message ("please call us back") or transfer the call to a waiting agent to perform an additional identification test of the person being called. =20 I agree that for the sake of getting a secure identifier out we should focus on the called party identifying the caller, but as we look at architectural choices it would be good if whatever we choose does not rule out the usage by the calling party. Dan >On Jun 17, 2013, at 1:38 PM, Dan York wrote: > >> I would not necessarily restrict it to the "called party". This is the >> dominant use case we've been discussing, I.e that I receive a call and >> want to be as certain as possible about the identity of the endpoint >> calling me. >>=20 >> However, I could be calling out to my customers or clients and as the >> "calling party" would like to be as certain as possible that I am >>reaching >> the correct endpoint. Consider a bank wanting to reach a customer about >> issues with the customer's account - or to verify a recent transaction. >>Or >> a doctor's office want to relay results to a patient and wanting to be >> sure they are reaching the patient's number. >>=20 >> My understanding is that we are aiming to solve the "secure origin >> identification" challenge - and that could apply to either or both ends >>of >> the conversation. >>=20 >> Dan >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From hadriel.kaplan@oracle.com Mon Jun 17 14:03: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 DFE2521F9DCC for ; Mon, 17 Jun 2013 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=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 SknR5LQobwVs for ; Mon, 17 Jun 2013 14:03:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9121F9D72 for ; Mon, 17 Jun 2013 14:03:31 -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 r5HL3KM5016396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 21:03:21 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 r5HL3MCH009202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 21:03:23 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5HL3MIk009194; Mon, 17 Jun 2013 21:03:22 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 14:03:22 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 17 Jun 2013 17:03:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 21:03:41 -0000 On Jun 17, 2013, at 2:58 PM, "Peterson, Jon" = wrote: >=20 > I agree it would be great to find a technical approach to this that > simplified business relationships, but I don't think we can depend on > technical standards to restrain policy. That would be like stipulating > that intermediaries can't change RFC3261 request bodies in order to - = but > never mind. I don't think that analogy holds. Such a stipulation would fail because = the guys who run the SIP networks themselves *must* change the request = bodies to get things to actually *work*, for their users/customers. = Even if you think they change bodies to maintain existing charging = practices: this caller-id verification thing is completely new, which is = a horse of a different color. There are no existing charging practices = for this currently. I believe the closest things would be: 1) CNAM, for which typically the called party pays. I don't think the = *carriers* want it to be that way, but it is that way. This STIR work = could end up being quite disruptive to the CNAM providers, because one = could imagine a means of providing CNAM using the STIR infrastructure = and cutting out the CNAM providers. But to brutal about this: we don't = need the CNAM providers to buy into this STIR work, so we don't need to = care if it impacts their business or not. 2) NPAC-type databases, or anything already holding a bunch of = E.164-based record entries. I don't know what the business model is for = them - obviously you would know a crapload more about that than I would. = I don't *think* it would be disruptive to make *only* E.164 caller-id = certificates in the NPAC publicly and freely accessible for retrieval. = Maybe it would be disruptive. But again to be brutal: we don't even = really need the NPAC-type databases, although it would sure make things = a heck of a lot easier. But ultimately all we need is for the carriers = to want to do this, with some model they're ok with. > It is ingenious to turn the inability to authenticate queries > to the DNS into a virtue in this regard, but I'm still not sure I > understand how this model would really prevent middlemen from charging = if > they wanted to, short of recreating e164.arpa as some comparable = public > golden root.=20 I am indeed claiming/assuming we do create a golden root if we do this = DNS thing. I don't care if it's cid.arpa, cid.sipforum.org, a new gTLD, = or even hadriel.com.=20 I didn't say it prevented middlemen - even just purely as a practical = matter there will likely be middlemen to do the signing and verifying = for mom&pop carriers, for example. Or the CNAM provider might do the = verifying function for their customer carriers. They can charge their = customers however they like, including on a per-query basis (e.g., = private ENUM is already used for some CNAM providers today). -hadriel From richard@shockey.us Mon Jun 17 14:48: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 53CA821F9D9F for ; Mon, 17 Jun 2013 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.367 X-Spam-Level: X-Spam-Status: No, score=-101.367 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=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 173bBKQGWnQI for ; Mon, 17 Jun 2013 14:48:10 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id E713021F9D90 for ; Mon, 17 Jun 2013 14:48:09 -0700 (PDT) Received: (qmail 470 invoked by uid 0); 17 Jun 2013 21:47:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 17 Jun 2013 21:47:36 -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=+oidtv1+/PVbBA3omVOtGiitREentKFghnvS3hQlYUA=; b=Dd256IeZodovylZvwlNaOQ8bTKOQBFQWgZCsRLqUm6XGrSTvFUyEPzikjGUiOuzZh6EHfvN7PwjoGLC8uD+MK53G6hU7DOgZ8nuR43nfL/L0OhPh7rsNikyer6wPPbyD; Received: from [72.66.111.124] (port=55971 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UohGx-0002wT-Na; Mon, 17 Jun 2013 15:47:35 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Peterson, Jon'" References: In-Reply-To: Date: Mon, 17 Jun 2013 17:47:34 -0400 Message-ID: <026001ce6ba4$479e0530$d6da0f90$@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: AQGFOfZZOworZHkqyyGmqaBTJahtKwK9WJ6Smbbm22A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Henning Schulzrinne' Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 17 Jun 2013 21:48:14 -0000 2) NPAC-type databases, or anything already holding a bunch of E.164-based record entries. I don't know what the business model is for them - obviously you would know a crapload more about that than I would. I don't *think* it would be disruptive to make *only* E.164 caller-id certificates in the NPAC publicly and freely accessible for retrieval. Maybe it would be disruptive. But again to be brutal: we don't even really need the NPAC-type databases, although it would sure make things a heck of a lot easier. But ultimately all we need is for the carriers to want to do this, with some model they're ok with. [RS> ] Amen to that.. > It is ingenious to turn the inability to authenticate queries to the > DNS into a virtue in this regard, but I'm still not sure I understand > how this model would really prevent middlemen from charging if they > wanted to, short of recreating e164.arpa as some comparable public > golden root. I am indeed claiming/assuming we do create a golden root if we do this DNS thing. I don't care if it's cid.arpa, cid.sipforum.org, [RS> ] sipforum.org Humm I like that idea. :-) We tried that idea in SIP UA Config and it didn't fly too far. a new gTLD, or even hadriel.com. [RS> ] stir.org... we need to support the Internet Society. I didn't say it prevented middlemen - even just purely as a practical matter there will likely be middlemen to do the signing and verifying for mom&pop carriers, for example. Or the CNAM provider might do the verifying function for their customer carriers. They can charge their customers however they like, including on a per-query basis (e.g., private ENUM is already used for some CNAM providers today). [RS> ] I remember I wrote the ENUM CNAM draft that everyone in the IETF hated but everyone else implemented. That said it's not unreasonable to discuss rational business models here since in one form another it will be the service providers that have the ultimate say in deployment. I don't care if its ATT, VZ, Telefonica, Bell Canada, Telus or Rostelcom, FT DT BT TI or whatever. If it's not simple and implementable within the rough protocol stack of IMS and the SBC's it's a non-starter. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Mon Jun 17 16:03: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 8E1BE21F9E82 for ; Mon, 17 Jun 2013 16:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 7FaqvqwMxOrt for ; Mon, 17 Jun 2013 16:03:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id F403621F9E7F for ; Mon, 17 Jun 2013 16:03:15 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5HN33xK025857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 23:03: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 r5HN31af027059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 23:03:02 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 r5HN314O027043; Mon, 17 Jun 2013 23:03:01 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jun 2013 16:03:01 -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: <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> Date: Mon, 17 Jun 2013 19:02:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <389B18F9-090A-49E1-BC89-9080EC8BE957@oracle.com> References: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DD0D4@ex2k10mb2.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] current draft 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, 17 Jun 2013 23:03:26 -0000 On Jun 17, 2013, at 12:04 PM, Michael Hammer = wrote: > If the DNS is involved, I think that there is an IAB draft/RFC that = says the > DNS should not be used for all things. Yes, and it's a fair point - not that the IAB's RFC is fair or even = valid - but it's fair point that a very big downside of using DNS for = STIR is: we'd be using DNS, which means we'd never be able to extend it = if we needed to. We'd have to be very sure it's the right solution for = the problem. -hadriel From jon.peterson@neustar.biz Mon Jun 17 17:47: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 C939121F9DD5 for ; Mon, 17 Jun 2013 17:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_34=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 BUa03nt7xsNB for ; Mon, 17 Jun 2013 17:47:29 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E621F9DC3 for ; Mon, 17 Jun 2013 17:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371516390; x=1686868522; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=6wwccXKFBl jqgUmEhEKWJjqKmpTzwO5WqHn0i5m4B3A=; b=SylhoP+ZLQ+j+DNVIudfdyfypv Hq+WQoUP1nS9vx+i8/IK9S9huiLyJTVHAD/ay6znRqxRxCU6E02XM6nDzg6A== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21084104; Mon, 17 Jun 2013 20:46:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 20:47:18 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKAgAElawD//6FkgIAAmBwA///JN4A= Date: Tue, 18 Jun 2013 00:47: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.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: FXVsjxwlzXROaw1lsXAa9Q== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 00:47:42 -0000 Definitely I agree that there needs to be a root here, at least at the national level. A few people have commented that working from the national level makes more sense than trying to delegate something globally from on high. Choosing that scope could make it harder to guarantee your vision of a tariff-free identity, admittedly. I've name-dropped LoST a couple times here as a place to look for inspiration, perhaps. But at the end of the day I was also envisioning that this revisited identity system would still work for regular domain names per RFC4474, and that we'd probably even keep CID as an option for Identity-Info (or its successor). So I was anticipating there'd be diversity in the means by which credentials could be indicated by Identity-Info, and that having a "root" wouldn't be exclusive in that there are identifiers other than telephone numbers in the system too. So again, to the question of how golden the root is, I at least pictured a national-level root for telephone number identity that would, if at all possible, eliminate the problem of multiple trust anchors issuing credentials for the same identity. Just like the same cert could be included by CID or referred to by HTTP, though, I imagine there could be more than one protocol for getting at those credentials. As for whether or not we need NPAC-style databases - agreed that here we don't need most of the data that's in them (like, LRNs aren't obviously material to solving our problem), but the authority structures they reflect are absolutely integral to this. Ultimately, STIR proposes only to project onto the Internet the authority over numbers that is today administered in those databases. I'd hesitate to start talking about delivering CNAM via STIR lest we get into some serious mission creep. But perhaps more materially, a root which is completely public can begin to have privacy implications when we start looking at adding in more personally identifiable information to the system.=20 Jon Peterson Neustar, Inc. On 6/17/13 2:03 PM, "Hadriel Kaplan" wrote: > >On Jun 17, 2013, at 2:58 PM, "Peterson, Jon" >wrote: > >>=20 >> I agree it would be great to find a technical approach to this that >> simplified business relationships, but I don't think we can depend on >> technical standards to restrain policy. That would be like stipulating >> that intermediaries can't change RFC3261 request bodies in order to - >>but >> never mind. > >I don't think that analogy holds. Such a stipulation would fail because >the guys who run the SIP networks themselves *must* change the request >bodies to get things to actually *work*, for their users/customers. Even >if you think they change bodies to maintain existing charging practices: >this caller-id verification thing is completely new, which is a horse of >a different color. There are no existing charging practices for this >currently. > >I believe the closest things would be: >1) CNAM, for which typically the called party pays. I don't think the >*carriers* want it to be that way, but it is that way. This STIR work >could end up being quite disruptive to the CNAM providers, because one >could imagine a means of providing CNAM using the STIR infrastructure and >cutting out the CNAM providers. But to brutal about this: we don't need >the CNAM providers to buy into this STIR work, so we don't need to care >if it impacts their business or not. > >2) NPAC-type databases, or anything already holding a bunch of >E.164-based record entries. I don't know what the business model is for >them - obviously you would know a crapload more about that than I would. >I don't *think* it would be disruptive to make *only* E.164 caller-id >certificates in the NPAC publicly and freely accessible for retrieval. >Maybe it would be disruptive. But again to be brutal: we don't even >really need the NPAC-type databases, although it would sure make things a >heck of a lot easier. But ultimately all we need is for the carriers to >want to do this, with some model they're ok with. > > >> It is ingenious to turn the inability to authenticate queries >> to the DNS into a virtue in this regard, but I'm still not sure I >> understand how this model would really prevent middlemen from charging >>if >> they wanted to, short of recreating e164.arpa as some comparable public >> golden root.=20 > >I am indeed claiming/assuming we do create a golden root if we do this >DNS thing. I don't care if it's cid.arpa, cid.sipforum.org, a new gTLD, >or even hadriel.com. > >I didn't say it prevented middlemen - even just purely as a practical >matter there will likely be middlemen to do the signing and verifying for >mom&pop carriers, for example. Or the CNAM provider might do the >verifying function for their customer carriers. They can charge their >customers however they like, including on a per-query basis (e.g., >private ENUM is already used for some CNAM providers today). > >-hadriel > From hgs@cs.columbia.edu Mon Jun 17 18:47: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 A9E1621F9BB3 for ; Mon, 17 Jun 2013 18:47:22 -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 iGk1oHyQ939Q for ; Mon, 17 Jun 2013 18:47:16 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id B767721F9BBA for ; Mon, 17 Jun 2013 18:47:16 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5I1l729013928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 21:47:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <453B19AF-088C-4859-8BEB-D5437B32456B@oracle.com> Date: Mon, 17 Jun 2013 21:47:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <453B19AF-088C-4859-8BEB-D5437B32456B@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: Michael Hammer , Dan York , "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] Not just "called party" - Re: current draft 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, 18 Jun 2013 01:47:22 -0000 I tend to agree (particularly given that we just had a house-sitter = watching our home, and I most definitely don't want the bank to take his = identity for ours). It would, e.g., for two-factor authentication, be useful to be able to = tell if a number has been redirected. I don't see much hope there, = however - if you have a malicious app on your phone that redirects the = call to the impostor, the phone is dutifully going to respond that the = call has indeed reached the right number. On Jun 17, 2013, at 3:04 PM, Hadriel Kaplan wrote: >=20 > For sake of focus and having a prayer of getting this done before we = all retire, I think we should focus exclusively on caller-id = reputability. No bank would ever trust this type of thing for = called-party identity anyway, because it only identifies phone numbers = not humans - i.e., at best it identifies a phone, not the person on the = other end. Thus they'll have to ask you a bunch of identifying = questions anyway. >=20 > -hadriel >=20 From hgs@cs.columbia.edu Mon Jun 17 18:57: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 9037721E8053 for ; Mon, 17 Jun 2013 18:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 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 edg2VS-rqAn2 for ; Mon, 17 Jun 2013 18:56:58 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4A21E8050 for ; Mon, 17 Jun 2013 18:56:58 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5I1utKW015735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 21:56:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 17 Jun 2013 21:56:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 01:57:03 -0000 For number assignment, we currently have an industry-cooperative model = (NANC, North American Numbering Council) that ensures that the system is = run reasonably efficiently and for the benefit of the industry = participants. Clearly, this isn't the only model, but I suspect there = are existing arrangements that can be extended. (Also, since the large = carriers are likely to both originate and validate a huge fraction of = the legitimate calls, there are built-in incentives for reasonable = behavior. For other behaviors, there is always 47 USC 201(b).) On Jun 17, 2013, at 2:58 PM, Peterson, Jon wrote: >=20 > I agree it would be great to find a technical approach to this that > simplified business relationships, but I don't think we can depend on > technical standards to restrain policy. That would be like stipulating > that intermediaries can't change RFC3261 request bodies in order to - = but > never mind. It is ingenious to turn the inability to authenticate = queries > to the DNS into a virtue in this regard, but I'm still not sure I > understand how this model would really prevent middlemen from charging = if > they wanted to, short of recreating e164.arpa as some comparable = public > golden root. Without it, there will always be ways that nation-states > could restrict access to queries from outside their borders, say, = unless > they go through this for-pay VPN or what have you. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/17/13 10:37 AM, "Hadriel Kaplan" = wrote: >=20 >>=20 >> On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" = >> wrote: >>=20 >>> I think the advantages below, with the exception of 4, would be true = of >>> any golden root we created for whatever protocol, be it HTTP or >>> something >>> else. I'm sure I could define an HTTP golden root such that the >>> verification service could synthesize the proper fetch request from = the >>> URI in the =46rom with an Identity-Info, one that updated in real = time so >>> you never needed to worry about revocation, one for which there was = only >>> one CA, and which you could locally cache (well, okay, 5 does = conflict a >>> bit with 2). >>=20 >> Sure, there's no debate one could replicate the DNS protocol and >> architecture to use HTTP as the accessing protocol instead of DNS >> query/response. I have no idea why one would want to make a simple >> database query protocol heavier for no benefit gain, but sure it's >> possible. :) >>=20 >>=20 >>> Also, all of the (snipped) concerns you raised about access control, >>> middlemen, charging, etc are just as likely to arise for DNS as for = any >>> other proposal. >>=20 >> No, they're not. For the middlemen issue, middlemen are of course = also >> possible using a DNS approach (they already exist today), but the >> protocol used for the client to access the middleman would be >> well-specified, because it's exactly the same as that used for cases >> where there is no middleman: DNS. >>=20 >> With regards to the access control and charging, the important point = is >> DNS would make it virtually impossible to *have* an access control = and >> charging model for queries. The protocol's characteristics actually = make >> it practically impossible to do. Country-A couldn't charge Country-B = to >> access the calling cert info for Country-A; and Carrier-A couldn't = charge >> Carrier-B to access the calling cert info for Carrier-A. Instead, >> Country-A would incur the cost for managing their own E.164 entries = in >> DNS, and likewise Country-B pays for Country-B's numbers; or = Carrier-A >> would incur the cost for their E.164 numbers, and likewise Carrier-B. >>=20 >> I know that's a controversial position. It means deciding, up front, >> that the only supportable pricing model for this thing in the grand = scale >> would be the same as for DNS domain names: charging only for >> adding/managing entries in the database, not charging _other_ = entities >> per-query of the database. I think (but don't know) that this would >> actually make this thing easier to get adoption for. At least in my >> simple naive view, it might help international adoption if the = decisions >> each country makes are only technical and logistic for their own = country, >> rather than involve money between countries. >>=20 >> [Note: this doesn't mean NPAC can't be used for this database in the >> NANP, even though NPAC is a closed model and charged for query access = I >> think.] >>=20 >> -hadriel >>=20 >=20 >=20 From hgs@cs.columbia.edu Mon Jun 17 19:01: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 1C7D021F8E98 for ; Mon, 17 Jun 2013 19:01:25 -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 1OgYehDUilGM for ; Mon, 17 Jun 2013 19:01:20 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5328A21F9B8E for ; Mon, 17 Jun 2013 19:01:20 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5I21IWE016485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 22:01:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4AFB94AF-03E0-4AF9-B04D-C45C99C06BBD@oracle.com> Date: Mon, 17 Jun 2013 22:01:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13DABAE1-72D4-44C5-8211-A4A7F79DDCE4@cs.columbia.edu> References: <7E81F8CD-8C7C-45B0-812A-FF8B056680A3@oracle.com> <018b01ce6b84$c2d72da0$488588e0$@shockey.us> <4AFB94AF-03E0-4AF9-B04D-C45C99C06BBD@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 02:01:25 -0000 For the boring details, see http://www.nanc-chair.org/ See http://www.nanc-chair.org/docs/documents.html ("Contribution = factor") for the latest. On Jun 17, 2013, at 2:13 PM, Hadriel Kaplan wrote: >=20 > On Jun 17, 2013, at 2:01 PM, "Richard Shockey" = wrote: >=20 >>=20 >> [Note: this doesn't mean NPAC can't be used for this database in the = NANP, >> even though NPAC is a closed model and charged for query access I = think.] >> [RS> ]=20 >>=20 >> [RS> ] Not since 2009. The NPAC like most national numbering = databases are >> now operated on fixed price contracts. The days of transaction based = or dip >> charges are long long gone. Cost recovery is usually based on the = number of >> entries or TN's in the data base and an annual allocation model = approved by >> the national regulator.=20 >=20 > Excellent. Then there's no problem on that front, either. :) >=20 > -hadriel >=20 >=20 From hgs@cs.columbia.edu Mon Jun 17 19:22: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 79F8421F9CCA for ; Mon, 17 Jun 2013 19:22:04 -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 zzR0Rhqovmh9 for ; Mon, 17 Jun 2013 19:21:58 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7321F9C8E for ; Mon, 17 Jun 2013 19:21:58 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5I2Lpg1021402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 22:21:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 17 Jun 2013 22:21:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 18 Jun 2013 02:22:04 -0000 I've been trying diligently to avoid any ownership terminology - if they = have any similarity to IP-related things, it's probably much more like = IP addresses: you have to show need and you can't always take them with = you. (For landline, it's *local* number portability. If you obtained a = 212 number, you can't get a landline in LA with that number, at least at = the moment. You can't request a specific number, even if it is = available, etc.) On Jun 17, 2013, at 1:46 PM, Peterson, Jon wrote: >=20 > You may know more about number portability than me, but I don't agree = with > your assessment of it here. At best, I'd say that number portability = in > America allows consumers to choose which carrier "owns" a number. This = is > also a reason I keep putting scare quotes around "owns," because the > assumptions of the DNS don't apply to users of telephone numbers, at = least > not in our current regulatory environment. If you are a registrant, = you > have the authority to configure your zone - that sounds close enough = to be > ownership to me (even though the UDRP or ICE can end your ownership = under > extreme conditions). If you have a telephone number assigned to you, a > carrier still decides what number it rings. From hgs@cs.columbia.edu Mon Jun 17 19:49: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 34A3D21E804E for ; Mon, 17 Jun 2013 19:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 93hlon9xJOCp for ; Mon, 17 Jun 2013 19:49:38 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14011E80D3 for ; Mon, 17 Jun 2013 19:49:38 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5I2nZ3s023987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 22:49:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <62BC978C-4C84-42CB-B1ED-C71209956B33@oracle.com> Date: Mon, 17 Jun 2013 22:49:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <417599D2-43FB-4B15-9B31-2C36E34AB2A8@cs.columbia.edu> References: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu> <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com> <4C2FC962-375E-4886-A15A-100E0031FE2D@cs.columbia.edu> <62BC978C-4C84-42CB-B1ED-C71209956B33@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 02:49:44 -0000 On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote: >=20 > On Jun 16, 2013, at 5:39 PM, Henning Schulzrinne = wrote: >=20 >>> I mean ultimately some of us might want to actually implement the = signing and verification into our systems. If it uses public-key = signatures, then we need a standardized protocol by which our systems = can query for a certificate signed by some authority we trust for a = given E.164 number. If DNS tells us "go look over at FOO": then what = standardized protocol does FOO use that we need to implement? >>=20 >> Wouldn't plain HTTPS do the trick, as in 4474? >=20 > Of course that's one possibility - my only point was we can't just = make the solution be "have DNS refer to another database"; we have to = specify what that referred-to database protocol would be so we can use = it. And if we're going to do that, then just stick that URL in the = Identity-Info header and avoid DNS. One of the advantages of the DNS = proposal was the DNS would *be* the database access protocol, and we = wouldn't need a URL in the Identity-Info header - we wouldn't even need = the header at all. In this split model, you could do a partial match, e.g., by country code = and then use DDDS/ENUM-style translation to get the URL, e.g., starting = with +1-202-555-1234 +1 translates to=20 https://oldmoon.com/12025551234 NAPTR 10 100 "u" "E2U+https" "!^.*$!https:\1@oldmoon.com!" (I'm not a DDDS expert, so this is likely wrong, but hopefully = illustrates the idea.) >=20 >=20 >> * Very small number of entities (1-10ish per country code) sign = "public key X is entitled to use TN [range] A". The cert is conveyed in = some proprietary fashion to the number holder, similar to how today's = web CA's deliver certs to their customers. A single entity can have any = number of public keys, if they want to obscure their number holdings or = for operational reasons. Working group to-do: Define appropriate X.509 = content for numbers. >=20 > The "magic" part of that which I was referring to was how a CA would = know what entities are entitled to what TNs, and for which various = country-codes. For example, let's assume Thawte is a trusted CA for = E.164's for +1 NANP... when some mom&pop "carrier" gets a number ported = into them, how does the process work to get Thawte to agree that mom&pop = now owns the ported number, and that the previous CA (if it's different) = revokes it for its previous carrier? When mom&pop get a number block, = how does Thawte verify that? I mentioned earlier the three models (single national = regulator-sponsored CA, CA with delegation and proof-of-possession CA). = You seem to refer to the third option, in which case we're back to the = webPKI model of trusting a finite number of CAs, possibly with = DANE-style assistance. I wouldn't rule out this option if others fail, = but it may not be necessary or optimal in this case, given the = properties of phone numbers. (Given the namespace issues, you'd then = likely go back to having a single logical database to keep track of the = CA for each number, run by a single trusted entity, which doesn't seem = to buy you much decentralization.) >>=20 >=20 > I'm not so sure. If we actually use the literal URL to get the cert, = then all the HTTPS servers have to be accessible to any querying device = of any carrier in the World. That doesn't scale if "access control" is = involved and charging for it. If we expect some service bureaus act as = middlemen for this retrieval instead, to alleviate the headache of = billing and access control between all carriers in the world, then we = have to create some standard way for the devices in the carriers to talk = to the middlemen and give them the URL for each call and get the cert or = have the signature verified; and that's assuming that their particular = middleman has a relationship with all databases in the World to access = the URL, or else they too have to use a protocol to give the URL to = another middleman, etc. That's what CDNs are made for... The originating entity has an inherent = interest in having the call go through. If my carrier charges a lot for = access to my cert, and receiving carriers decide not to validate my = number, I'm very likely to find an alternative (or complain to my = national regulator or congressman; look up "rural call completion" if = you don't think that call delivery doesn't get congressional attention.) > The advantages of using the DNS as the repository for the cert data, = instead of giving an HTTP URL in a header to get a cert from, are: > 1) There's no header needed for carrying a URL. Assuming we can all agree on a single, global DNS tree. That seems like = a big "if" at the moment. I suspect we all agree at this point that we = don't want to rule this out, so DNS seems like a good option to pursue = as ONE option. Relying on this happening as the ONLY option seems risky, = however. The operational coordination for certs and distributed = retrieval databases seems lower - the number assignment entity simply = has to somehow convey certs to a relative handful (dozens to = low-thousands) of entities it already conveys data to today. ftp or = mailing a USB stick will do in a pinch, if need be. No need to operate = anything real-time. I'm trying to lower the bar for deployment, with as little coordinated = machinery as possible. > 2) There's no need to worry about revocation, because the instant a = number changes ownership, the DNS entry of its cert changes. > 3) There're far fewer potential CAs to have to trust - ideally only = one per country-code, the same one that's authoritative for its = country-code branch of the DNS tree; and we'd be using DNSSEC so its = cert is in the DNS, and it's the signer of its entries. In fact you = might be able to just have the raw public key in the DNS instead of the = whole cert, because the rest of the DNSSEC-provided info is redundant = with the stuff in a cert for this use-case. > 4) It's generally faster, and with tighter client control for = retransmit/timeout because it's UDP. With caching, the data is likely very local either way. > 5) For bigger carriers, they can have local DNS servers with copies of = the frequently accessed data (e.g., local nation E.164s) that their = verification systems can query. Same for any other retrieval protocol, I suspect. >=20 > -hadriel >=20 >=20 From rlb@ipv.sx Mon Jun 17 20:57: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 2AA4D21E8050 for ; Mon, 17 Jun 2013 20:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 PebItdeJuyeJ for ; Mon, 17 Jun 2013 20:57:15 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2356211E80DC for ; Mon, 17 Jun 2013 20:57:12 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so4031460obc.24 for ; Mon, 17 Jun 2013 20:57:11 -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=ZPjipnyAh3omMEQ+cA9eVHA4UaeCGsRmURN5tLl9Kbg=; b=NSClF9KL9eAGME/Od+Zj+Ya3l/XR6q//VxQFM0cMiviwRUxXPkm/FTreIlbcx18z6I lbiLS2JBs5SsMve4aPpGbuKKKOcl+ZDQYN9TzHSAgO4R4qB8Or96mONKIUcIXKaJZhlR CZBLzSNMKQGkMf62F067oJxUqtVjNO5NphLkjc9H8dh7ksPqiBwvw8OOFRXdw1++jOA3 c0a1Wb2F8xFk8Qin6qIST2ZMKe5TDY8QuPAncuJDFtzb/T/9bTdfwX1cV7kNi7cwgeCm 38dpPEZfPfWULdaW+DKxn3hLMFhw1UgnOGCOE08dFZsYwVHBncv8sBwc7ydzUgl8E14R SPbA== MIME-Version: 1.0 X-Received: by 10.182.237.77 with SMTP id va13mr11009729obc.65.1371527831535; Mon, 17 Jun 2013 20:57:11 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Mon, 17 Jun 2013 20:57:11 -0700 (PDT) X-Originating-IP: [12.104.13.2] In-Reply-To: <024201ce6b98$e3bbcda0$ab3368e0$@shockey.us> References: <024201ce6b98$e3bbcda0$ab3368e0$@shockey.us> Date: Mon, 17 Jun 2013 23:57:11 -0400 Message-ID: From: Richard Barnes To: Richard Shockey Content-Type: multipart/alternative; boundary=e89a8ff1cdcc32d5d704df65b596 X-Gm-Message-State: ALoCoQl28gGjXHfpNJHaW33Lc1DgeBpRcqe5UmuaMupA5iHPNwxXwuJ8uzymRT2G9RVRtob4UfZd Cc: "stir@ietf.org" Subject: Re: [stir] Just out of curiosity .. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 03:57:19 -0000 --e89a8ff1cdcc32d5d704df65b596 Content-Type: text/plain; charset=ISO-8859-1 The current plan is to have a BoF, in light of the need for cross-area participation. Brian Rosen and Russ Housley have kindly agreed to co-chair the BoF. On Mon, Jun 17, 2013 at 4:26 PM, Richard Shockey wrote: > Considering the timing has a decision been made on BOF vs DISPATCH? **** > > ** ** > > 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**** > > ** ** > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --e89a8ff1cdcc32d5d704df65b596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The current plan is to have a BoF, in light of the need fo= r cross-area participation. =A0Brian Rosen and Russ Housley have kindly agr= eed to co-chair the BoF.



On Mon,= Jun 17, 2013 at 4:26 PM, Richard Shockey <richard@shockey.us> wrote:

Considering the timing has a decis= ion been made on BOF vs DISPATCH?

=A0

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=

=A0


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


--e89a8ff1cdcc32d5d704df65b596-- From philippe.fouquart@orange.com Tue Jun 18 05:55: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 10B6321F99B7 for ; Tue, 18 Jun 2013 05:55:40 -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, 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 sm76Orvjygcy for ; Tue, 18 Jun 2013 05:55:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2921F9EE1 for ; Tue, 18 Jun 2013 05:55:13 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2FCF13B4E5A; Tue, 18 Jun 2013 14:55:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0F6284C07D; Tue, 18 Jun 2013 14:55:12 +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, 18 Jun 2013 14:55:11 +0200 From: To: Henning Schulzrinne , "Peterson, Jon" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxLcUAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AIAAJmCAgAAQaYCAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp2gIAAEO2AgABhe4CAABagAIAAEU+AgAA97YCAABdWgIAAkrUAgAAi54CAAJAeAIAAxmUg Date: Tue, 18 Jun 2013 12:55:11 +0000 Message-ID: <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> In-Reply-To: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] 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.5.21.113319 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 18 Jun 2013 12:55:40 -0000 FWIW, this notion of ownership of E.164 resources has indeed always been di= stinct of that of assignment. E.164 is actually governed by the overarching= principles of E.190, which on this says that "assignment confers use of th= e resource but does not imply ownership by the assignee".=20 In numbering plans I'm familiar with, this principle translates into an art= icle in all NRA assignment rulings stating that the assignment doesn't conf= er the right to protect a number as a trademark for instance. Or some limit= ations in time and transfer under conditions.=20 Although people sometimes like using ownership as a shortcut, it's more of = a right of use really. (I'm sure some here will remember discussions on the= notion of carrier of record with eye-watering nostalgia)=20 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 Hen= ning Schulzrinne Sent: Tuesday, June 18, 2013 4:22 AM To: Peterson, Jon Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter I've been trying diligently to avoid any ownership terminology - if they ha= ve any similarity to IP-related things, it's probably much more like IP add= resses: you have to show need and you can't always take them with you. (For= landline, it's *local* number portability. If you obtained a 212 number, y= ou can't get a landline in LA with that number, at least at the moment. You= can't request a specific number, even if it is available, etc.) On Jun 17, 2013, at 1:46 PM, Peterson, Jon wrote: >=20 > You may know more about number portability than me, but I don't agree with > your assessment of it here. At best, I'd say that number portability in > America allows consumers to choose which carrier "owns" a number. This is > also a reason I keep putting scare quotes around "owns," because the > assumptions of the DNS don't apply to users of telephone numbers, at least > not in our current regulatory environment. If you are a registrant, you > have the authority to configure your zone - that sounds close enough to be > ownership to me (even though the UDRP or ICE can end your ownership under > extreme conditions). If you have a telephone number assigned to you, a > carrier still decides what number it rings. _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From richard@shockey.us Tue Jun 18 07:06: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 BE78421F9B4C for ; Tue, 18 Jun 2013 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.313, 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 Dxp9fIttkAp6 for ; Tue, 18 Jun 2013 07:06:44 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 801A221F9B1C for ; Tue, 18 Jun 2013 07:06:44 -0700 (PDT) Received: (qmail 27199 invoked by uid 0); 18 Jun 2013 14:06:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 18 Jun 2013 14:06:22 -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=C45omENgyHKgsYlmNs+IfUX/WinAY0+5lT32Gz45rb8=; b=XE49hc6OTOiIi4INbSuakK5YsmXqqB4QtVp/c7ammCx7U6eww9GJOflqgGm6RjXiIw5gotCpzqqxRzo5Qtpf2pP+VPlIpme5ciVceDB3E2dk+VcC5hLa/eH4a9p761v6; Received: from [72.66.111.124] (port=49588 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UowYA-0007rw-BP; Tue, 18 Jun 2013 08:06:22 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , References: In-Reply-To: Date: Tue, 18 Jun 2013 10:06:20 -0400 Message-ID: <00ce01ce6c2d$02edf380$08c9da80$@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: AQGFOfZZOworZHkqyyGmqaBTJahtKwK49BLombgVa/A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 14:06:48 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, June 17, 2013 9:57 PM To: Peterson, Jon Cc: stir@ietf.org; Hadriel Kaplan Subject: Re: [stir] current draft charter - ENUM and databases For number assignment, we currently have an industry-cooperative model (NANC, North American Numbering Council) that ensures that the system is run reasonably efficiently [RS> ] you are very very charitable Henning. To your point we also have industry operational entities such as the NAPM North American Portability Management LLC which actually contracts for the LNP function in the US where the NANC is more a policy body and is a formal US TAC under the Federal Advisory Act of 1972 and the COIN Association in the Netherlands that runs the LNP DB there and is a Non Profit Corporation of 70 Dutch Carriers. There are lots of these in the EC. In Canada there is the Canadian Steering Committee on Numbering. In the UK there is NICC though OFFCOM directly administers the +44 plan. http://www.niccstandards.org.uk/ http://www.crtc.gc.ca/cisc/eng/cisf3f.htm The term of art for these cooperative industry entities comes from the UK QUANGO.. Quasi Non Governmental whatever's. Operationally no matter what technical model selected virtually every nation state has some entity that can deal with these kinds of things. That is the least of our problems. and for the benefit of the industry participants. Clearly, this isn't the only model, but I suspect there are existing arrangements that can be extended. (Also, since the large carriers are likely to both originate and validate a huge fraction of the legitimate calls, there are built-in incentives for reasonable behavior. For other behaviors, there is always 47 USC 201(b).) [RS> ] Correct! We will now return you to your regularly scheduled program. On Jun 17, 2013, at 2:58 PM, Peterson, Jon wrote: > > I agree it would be great to find a technical approach to this that > simplified business relationships, but I don't think we can depend on > technical standards to restrain policy. That would be like stipulating > that intermediaries can't change RFC3261 request bodies in order to - > but never mind. It is ingenious to turn the inability to authenticate > queries to the DNS into a virtue in this regard, but I'm still not > sure I understand how this model would really prevent middlemen from > charging if they wanted to, short of recreating e164.arpa as some > comparable public golden root. Without it, there will always be ways > that nation-states could restrict access to queries from outside their > borders, say, unless they go through this for-pay VPN or what have you. > > Jon Peterson > Neustar, Inc. > > On 6/17/13 10:37 AM, "Hadriel Kaplan" wrote: > >> >> On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" >> >> wrote: >> >>> I think the advantages below, with the exception of 4, would be true >>> of any golden root we created for whatever protocol, be it HTTP or >>> something else. I'm sure I could define an HTTP golden root such >>> that the verification service could synthesize the proper fetch >>> request from the URI in the From with an Identity-Info, one that >>> updated in real time so you never needed to worry about revocation, >>> one for which there was only one CA, and which you could locally >>> cache (well, okay, 5 does conflict a bit with 2). >> >> Sure, there's no debate one could replicate the DNS protocol and >> architecture to use HTTP as the accessing protocol instead of DNS >> query/response. I have no idea why one would want to make a simple >> database query protocol heavier for no benefit gain, but sure it's >> possible. :) >> >> >>> Also, all of the (snipped) concerns you raised about access control, >>> middlemen, charging, etc are just as likely to arise for DNS as for >>> any other proposal. >> >> No, they're not. For the middlemen issue, middlemen are of course >> also possible using a DNS approach (they already exist today), but >> the protocol used for the client to access the middleman would be >> well-specified, because it's exactly the same as that used for cases >> where there is no middleman: DNS. >> >> With regards to the access control and charging, the important point >> is DNS would make it virtually impossible to *have* an access control >> and charging model for queries. The protocol's characteristics >> actually make it practically impossible to do. Country-A couldn't >> charge Country-B to access the calling cert info for Country-A; and >> Carrier-A couldn't charge Carrier-B to access the calling cert info >> for Carrier-A. Instead, Country-A would incur the cost for managing >> their own E.164 entries in DNS, and likewise Country-B pays for >> Country-B's numbers; or Carrier-A would incur the cost for their E.164 numbers, and likewise Carrier-B. >> >> I know that's a controversial position. It means deciding, up front, >> that the only supportable pricing model for this thing in the grand >> scale would be the same as for DNS domain names: charging only for >> adding/managing entries in the database, not charging _other_ >> entities per-query of the database. I think (but don't know) that >> this would actually make this thing easier to get adoption for. At >> least in my simple naive view, it might help international adoption >> if the decisions each country makes are only technical and logistic >> for their own country, rather than involve money between countries. >> >> [Note: this doesn't mean NPAC can't be used for this database in the >> NANP, even though NPAC is a closed model and charged for query access >> I think.] >> >> -hadriel >> > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Tue Jun 18 08:06: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 A4BDC21F9C40 for ; Tue, 18 Jun 2013 08:06:55 -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.466, 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 6cC3L29JxZpB for ; Tue, 18 Jun 2013 08:06:50 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 8F88821F9C57 for ; Tue, 18 Jun 2013 08:06:50 -0700 (PDT) Received: (qmail 19872 invoked by uid 0); 18 Jun 2013 15:06:27 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 18 Jun 2013 15:06: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:Cc:To:From; bh=UHaBXgLTj3dsDxaJsL+rYo6C7MYiAkjEcnXrjXn6vuw=; b=XutMVL/8bn7DWep7weJEuYjm+voJYbMHiS+xPIX0ulqoqmdpASdo0xO7wWXHOiyIeK45aJZlTgMDyy35gfq5OGWFTGZsAn8MR0zoPxmnm3GEsh6398Nk9BdQ8NBGM3zm; Received: from [72.66.111.124] (port=49757 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UoxUI-0000pB-Hp; Tue, 18 Jun 2013 09:06:26 -0600 From: "Richard Shockey" To: , "'Henning Schulzrinne'" , "'Peterson, Jon'" References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 18 Jun 2013 11:06:24 -0400 Message-ID: <010701ce6c35$672f6970$358e3c50$@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: AQKuaRI35jEWN845zLC+VLogCdnM2gMMymFcAf9PklyXUzVrUA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, dcrocker@bbiw.net Subject: Re: [stir] current draft 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, 18 Jun 2013 15:06:55 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, June 18, 2013 8:55 AM To: Henning Schulzrinne; Peterson, Jon Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter FWIW, this notion of ownership of E.164 resources has indeed always been distinct of that of assignment. E.164 is actually governed by the overarching principles of E.190, which on this says that "assignment confers use of the resource but does not imply ownership by the assignee". In numbering plans I'm familiar with, this principle translates into an article in all NRA assignment rulings stating that the assignment doesn't confer the right to protect a number as a trademark for instance. Or some limitations in time and transfer under conditions. [RS> ] [RS> ] In general you are right though there are some odd corner cases. Specifically the free phone number ranges 800 and 8XX ranges in the US and Canada. Although people sometimes like using ownership as a shortcut, it's more of a right of use really. (I'm sure some here will remember discussions on the notion of carrier of record with eye-watering nostalgia) [RS> ] I wouldn't call it nostalgia, more a review of the battle scars and the cumulative effects of cranial concussion. 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 Henning Schulzrinne Sent: Tuesday, June 18, 2013 4:22 AM To: Peterson, Jon Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter I've been trying diligently to avoid any ownership terminology - if they have any similarity to IP-related things, it's probably much more like IP addresses: you have to show need and you can't always take them with you. (For landline, it's *local* number portability. If you obtained a 212 number, you can't get a landline in LA with that number, at least at the moment. You can't request a specific number, even if it is available, etc.) On Jun 17, 2013, at 1:46 PM, Peterson, Jon wrote: > > You may know more about number portability than me, but I don't agree > with your assessment of it here. At best, I'd say that number > portability in America allows consumers to choose which carrier "owns" > a number. This is also a reason I keep putting scare quotes around > "owns," because the assumptions of the DNS don't apply to users of > telephone numbers, at least not in our current regulatory environment. > If you are a registrant, you have the authority to configure your zone > - that sounds close enough to be ownership to me (even though the UDRP > or ICE can end your ownership under extreme conditions). If you have a > telephone number assigned to you, a carrier still decides what number it rings. _______________________________________________ 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Tue Jun 18 08:13: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 E4B1121F9965 for ; Tue, 18 Jun 2013 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 IHoTkZ-vfKzd for ; Tue, 18 Jun 2013 08:13:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1921F94DF for ; Tue, 18 Jun 2013 08:13:20 -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 r5IFD4QQ020896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jun 2013 08:13:09 -0700 Message-ID: <51C078F1.4020508@dcrocker.net> Date: Tue, 18 Jun 2013 08:12:49 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Shockey References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <010701ce6c35$672f6970$358e3c50$@shockey.us> In-Reply-To: <010701ce6c35$672f6970$358e3c50$@shockey.us> 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, 18 Jun 2013 08:13:10 -0700 (PDT) Cc: philippe.fouquart@orange.com, dcrocker@bbiw.net, stir@ietf.org, "'Peterson, Jon'" , 'Henning Schulzrinne' Subject: Re: [stir] current draft 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, 18 Jun 2013 15:13:26 -0000 On 6/18/2013 8:06 AM, Richard Shockey wrote: > Although people sometimes like using ownership as a shortcut, it's more of a > right of use really. (I'm sure some here will remember discussions on the > notion of carrier of record with eye-watering nostalgia) As someone who's been using the term ownership here, I'll note that I indeed meant it as an expedient and am happy to use whatever term is already common or that the group prefers. The 'right to use' is the important issue here, not the legality of ownership. Absent there being an established term, how about assignment and assignee, in place of ownership and owner? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Tue Jun 18 08:15: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 DC0B221E8084 for ; Tue, 18 Jun 2013 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 t53FLmxE9m6j for ; Tue, 18 Jun 2013 08:15:22 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F621E8063 for ; Tue, 18 Jun 2013 08:15:21 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 18 Jun 2013 08:15:21 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" , "richard@shockey.us" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxxKUAgAAL0QCAAIQGAIAAcu6AgAADDoCAABCAAIAAJmCAgAAQaYCAAADrAIAABUwAgABko4CAAOCpgIAAU3yAgAA76wCABBp2gIAAEOyAgABhfICAABagAIAAEU+AgAA97ICAABdXgIAAkrUAgAAi54CAAJAeAIAAsPWAgAAkqQCAAAHLgP//izgQ Date: Tue, 18 Jun 2013 15:15:20 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DE569@ex2k10mb2.corp.yaanatech.com> References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <010701ce6c35$672f6970$358e3c50$@shockey.us> <51C078F1.4020508@dcrocker.net> In-Reply-To: <51C078F1.4020508@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.200] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C4_01CE6C15.1E3A8DF0" MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "hgs@cs.columbia.edu" , "jon.peterson@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] current draft 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, 18 Jun 2013 15:15:26 -0000 ------=_NextPart_000_00C4_01CE6C15.1E3A8DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree. I had used it in the end-user perspective sense. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Tuesday, June 18, 2013 11:13 AM To: Richard Shockey Cc: philippe.fouquart@orange.com; dcrocker@bbiw.net; stir@ietf.org; 'Peterson, Jon'; 'Henning Schulzrinne' Subject: Re: [stir] current draft charter On 6/18/2013 8:06 AM, Richard Shockey wrote: > Although people sometimes like using ownership as a shortcut, it's > more of a right of use really. (I'm sure some here will remember > discussions on the notion of carrier of record with eye-watering > nostalgia) As someone who's been using the term ownership here, I'll note that I indeed meant it as an expedient and am happy to use whatever term is already common or that the group prefers. The 'right to use' is the important issue here, not the legality of ownership. Absent there being an established term, how about assignment and assignee, in place of ownership and owner? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00C4_01CE6C15.1E3A8DF0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx ODE1MTUxOVowIwYJKoZIhvcNAQkEMRYEFAw5R4GgGj1PqpjK1bZwLBJ1jGGtMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYPs+q1rrqR+vabiPvXgMcXC9D+qpzw1mXcBZp2YW nSYK+EcZAkpmWSJoB3qQOIuVQwjLDRjh7r++nHtoBfHMLjR76VY7EA1xhHzu0Mu+ilWBdLOZ4usa z8DdbO/PqhzGMHFTIIobdXnlVaS/BX5kxCCVr6lZGjbIWoBfVUg9Jow46VlFGOsD2uL2w4lFgGf4 nE93H2whbTlF9o4eQCttv8wbnriuZpFrSbSoNCPgbTnn+bzzaevg7VzhLojpGp2W6UDnIDPJpLTq Dj6AgEyS9BVbO855LprWkal7+SbRwGPh8WywhZJl2tnMDVGzW6sCYGGCJpv9bZzoo9a+ZdaiXwAA AAAAAA== ------=_NextPart_000_00C4_01CE6C15.1E3A8DF0-- From rlb@ipv.sx Tue Jun 18 08:17: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 7D16121F9A7C for ; Tue, 18 Jun 2013 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 toDpENOp2EO2 for ; Tue, 18 Jun 2013 08:17:22 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEF521F9A27 for ; Tue, 18 Jun 2013 08:17:22 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so4756478obc.17 for ; Tue, 18 Jun 2013 08:17:22 -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=x/upZVe582sILEfe/z0DrpyKLH/7FHDvSDefSYMpDS0=; b=eaR3lGD7V3zrmyJbmckezti088r/bOaYO51GrhrlKC5wg8VBvdS0yq2oJ4gpRyziEU UtoDVuW2dEaB1Ey/Nyg6f93pJvXKB8ZVrpj3ihUNC832EHZpqPj2HYYJATbjCHtGG99s GnNiMSpx64oE7a4qVhKRgokunFo+VpMa45Be9jD5TrGhx7KhxAtJBS7av7srokN8AMhW M1I3E3a1rqMiCzvAuU53S5HLDM3sQwIRcpSqxkDN5Vk9hPf87XFTuu6GbhVHJW/mf7uA mUngMWlXs/1zP/tE6GIQ0EyP2JCyaPZyG9nrrhadcjVYbHW1W2312YFMrafpDycl/FK4 5FQA== MIME-Version: 1.0 X-Received: by 10.182.60.2 with SMTP id d2mr12244246obr.75.1371568642012; Tue, 18 Jun 2013 08:17:22 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Tue, 18 Jun 2013 08:17:21 -0700 (PDT) X-Originating-IP: [128.33.85.80] In-Reply-To: <51C078F1.4020508@dcrocker.net> References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <010701ce6c35$672f6970$358e3c50$@shockey.us> <51C078F1.4020508@dcrocker.net> Date: Tue, 18 Jun 2013 11:17:21 -0400 Message-ID: From: Richard Barnes To: Dave Crocker Content-Type: multipart/alternative; boundary=089e015387dcb1537904df6f3561 X-Gm-Message-State: ALoCoQnuVqgFD9w4q2zFoE7gDz2UduQCKeF85oYL7k87DE7j+EZcCQcsOlTSP04cp2rgnzGuKsKO Cc: "philippe.fouquart@orange.com" , Henning Schulzrinne , "Peterson, Jon" , "stir@ietf.org" , Richard Shockey Subject: Re: [stir] current draft 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, 18 Jun 2013 15:17:26 -0000 --089e015387dcb1537904df6f3561 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 11:12 AM, Dave Crocker wrote: > On 6/18/2013 8:06 AM, Richard Shockey wrote: > >> Although people sometimes like using ownership as a shortcut, it's more >> of a >> right of use really. (I'm sure some here will remember discussions on the >> notion of carrier of record with eye-watering nostalgia) >> > > > As someone who's been using the term ownership here, I'll note that I > indeed meant it as an expedient and am happy to use whatever term is > already common or that the group prefers. The 'right to use' is the > important issue here, not the legality of ownership. > > Absent there being an established term, how about assignment and assignee, > in place of ownership and owner? That would be consistent with usage in the Internet number / RPKI space. The verb "to hold" is also used, e.g., the holder of number resources. --Richard > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ______________________________**_________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/**listinfo/stir > --089e015387dcb1537904df6f3561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 18, 2013 at 11:12 AM, Dave Crocker <dhc@dcro= cker.net> wrote:
On 6/18/2013 8:06 AM, Rich= ard Shockey wrote:
Although people sometimes like using ownership as a shortcut, it's more= of a
right of use really. (I'm sure some here will remember discussions on t= he
notion of carrier of record with eye-watering nostalgia)


As someone who's been using the term ownership here, I'll note that= I indeed meant it as an expedient and am happy to use whatever term is alr= eady common or that the group prefers. =A0The 'right to use' is the= important issue here, not the legality of ownership.

Absent there being an established term, how about assignment and assignee, = in place of ownership and owner?

That would= be consistent with usage in the Internet number / RPKI space. =A0The verb = "to hold" is also used, e.g., the holder of number resources.

--Richard

=A0


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/stir

--089e015387dcb1537904df6f3561-- From dhc@dcrocker.net Tue Jun 18 08:44: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 E37BD21F9ACA for ; Tue, 18 Jun 2013 08:44:06 -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 uYlPe7FkFs27 for ; Tue, 18 Jun 2013 08:44:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E161421F9AD5 for ; Tue, 18 Jun 2013 08:44:01 -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 r5IFhfEU022003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jun 2013 08:43:45 -0700 Message-ID: <51C0801F.6090101@dcrocker.net> Date: Tue, 18 Jun 2013 08:43:27 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 18 Jun 2013 08:43:45 -0700 (PDT) Cc: "stir@ietf.org" , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases 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, 18 Jun 2013 15:44:07 -0000 On 6/17/2013 5:47 PM, Peterson, Jon wrote: > But at the end of the day I was also envisioning that this revisited > identity system would still work for regular domain names per RFC4474, and > that we'd probably even keep CID as an option for Identity-Info (or its > successor). So I was anticipating there'd be diversity in the means by > which credentials could be indicated by Identity-Info, and that having a > "root" wouldn't be exclusive in that there are identifiers other than > telephone numbers in the system too. The task of the current effort is to be able to determine whether the value in the From header field is authorized for use. This means checking with an authority for the assignment of the value. (Forgive me, but on review I don't see any text in the draft charter that is as simple and direct as the above, in terms of stating the basic deliverable for this effort.) For each type of data that can go in the From field, there's likely to be a different assignment authority and very possibly important differences in the mechanisms for doing queries, to determine authorization. The desire for keeping things generic is understandinable; it's appealing. But I doubt there's an existence proof for its working on something of this scale and criticality over the open Internet. That is, take the current, known case and solve it as cleanly as possible. Trying to solve possible future alternatives is almost certainly a distraction, of the type that will introduce complexity and delays. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Tue Jun 18 08:45: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 25BC421F9AE2 for ; Tue, 18 Jun 2013 08:45:03 -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, HTML_MESSAGE=0.001, 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 KXOzsoNqKtPS for ; Tue, 18 Jun 2013 08:44:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BABBB21F9ACA for ; Tue, 18 Jun 2013 08:44:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0F9D532497D; Tue, 18 Jun 2013 17:44:54 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C5D9235C090; Tue, 18 Jun 2013 17:44:53 +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; Tue, 18 Jun 2013 17:44:53 +0200 From: To: Richard Barnes , Dave Crocker Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxLcUAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AIAAJmCAgAAQaYCAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp2gIAAEO2AgABhe4CAABagAIAAEU+AgAA97YCAABdWgIAAkrUAgAAi54CAAJAeAIAAxmUggAAPOQCAAAHLgIAAAUSAgAAoxkA= Date: Tue, 18 Jun 2013 15:44:53 +0000 Message-ID: <21650_1371570293_51C08075_21650_436_1_B5939C6860701C49AA39C5DA5189448B0A3864@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <010701ce6c35$672f6970$358e3c50$@shockey.us> <51C078F1.4020508@dcrocker.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_B5939C6860701C49AA39C5DA5189448B0A3864PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "stir@ietf.org" , Henning Schulzrinne , "Peterson, Jon" , Richard Shockey Subject: Re: [stir] current draft 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, 18 Jun 2013 15:45:03 -0000 --_000_B5939C6860701C49AA39C5DA5189448B0A3864PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Either of these would work fine for me. I don't want to make it sound more complex than necessary but would just no= te that using the term "assignee" is sometimes also tricky. For example, a = number range assignee may remain the same even though numbers have been por= ted out of that range. (Incidentally, in a number of national numbering pla= n, it's always the assignee's responsibility to provide an annual report on= the use of that range (and on all of its assigned ranges), which may there= fore oddly enough include numbers that have been ported out) Using your terms, in these cases, the holder has a number in a range which = is and remains assigned to a party it (the holder) has no relationship with. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, June 18, 2013 5:17 PM To: Dave Crocker Cc: Richard Shockey; FOUQUART Philippe OLNC/OLN; stir@ietf.org; Peterson, J= on; Henning Schulzrinne Subject: Re: [stir] current draft charter On Tue, Jun 18, 2013 at 11:12 AM, Dave Crocker > wrote: On 6/18/2013 8:06 AM, Richard Shockey wrote: Although people sometimes like using ownership as a shortcut, it's more of a right of use really. (I'm sure some here will remember discussions on the notion of carrier of record with eye-watering nostalgia) As someone who's been using the term ownership here, I'll note that I indee= d meant it as an expedient and am happy to use whatever term is already com= mon or that the group prefers. The 'right to use' is the important issue h= ere, not the legality of ownership. Absent there being an established term, how about assignment and assignee, = in place of ownership and owner? That would be consistent with usage in the Internet number / RPKI space. T= he verb "to hold" is also used, e.g., the holder of number resources. --Richard d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_B5939C6860701C49AA39C5DA5189448B0A3864PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Either of = these would work fine for me.

 = ;

I don't wa= nt to make it sound more complex than necessary but would just note that us= ing the term "assignee" is sometimes also tricky. For example, a number range assignee may remain the same even though numbers have been = ported out of that range. (Incidentally, in a number of national numbering = plan, it’s always the assignee's responsibility to provide an annual = report on the use of that range (and on all of its assigned ranges), which may therefore oddly enough include numb= ers that have been ported out)

 = ;

Using your= terms, in these cases, the holder has a number in a range which is and rem= ains assigned to a party it (the holder) has no relationship with. 

 = ;

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, June 18, 2013 5:17 PM
To: Dave Crocker
Cc: Richard Shockey; FOUQUART Philippe OLNC/OLN; stir@ietf.org; Pete= rson, Jon; Henning Schulzrinne
Subject: Re: [stir] current draft charter

 

On Tue, Jun 18, 2013 at 11:12 AM, Dave Crocker <<= a href=3D"mailto:dhc@dcrocker.net" target=3D"_blank">dhc@dcrocker.net&g= t; wrote:

On 6/18/2013 8:06 AM, Richard Shockey wrote:

Although people sometimes like using ownership as a = shortcut, it's more of a
right of use really. (I'm sure some here will remember discussions on the notion of carrier of record with eye-watering nostalgia)

 

As someone who's been using the term ownership here,= I'll note that I indeed meant it as an expedient and am happy to use whate= ver term is already common or that the group prefers.  The 'right to u= se' is the important issue here, not the legality of ownership.

Absent there being an established term, how about assignment and assignee, = in place of ownership and owner?

 

That would be consistent with usage in the Internet = number / RPKI space.  The verb "to hold" is also used, e.g.,= the holder of number resources.

 

--Richard

 

 



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
stir mailing list
stir@ietf.org
ht= tps://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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_B5939C6860701C49AA39C5DA5189448B0A3864PEXCVZYM12corpora_-- From philippe.fouquart@orange.com Tue Jun 18 08:54: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 2DE1721F9A58 for ; Tue, 18 Jun 2013 08:54:58 -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 dsOlx1qcf-mo for ; Tue, 18 Jun 2013 08:54:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B237421F9A43 for ; Tue, 18 Jun 2013 08:54:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 236E722D0AE; Tue, 18 Jun 2013 17:54:53 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 01A0527C046; Tue, 18 Jun 2013 17:54:53 +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; Tue, 18 Jun 2013 17:54:51 +0200 From: To: Richard Shockey , 'Henning Schulzrinne' , "'Peterson, Jon'" Thread-Topic: [stir] current draft charter Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxLcUAgAAL0QCAAIQHAIAAcu6AgAADDoCAABB/AIAAJmCAgAAQaYCAAADrAIAABU0AgABkooCAAOCqgIAAU3yAgAA76gCABBp2gIAAEO2AgABhe4CAABagAIAAEU+AgAA97YCAABdWgIAAkrUAgAAi54CAAJAeAIAAxmUggAAPOQCAACzt8A== Date: Tue, 18 Jun 2013 15:54:50 +0000 Message-ID: <29635_1371570893_51C082CD_29635_4142_1_B5939C6860701C49AA39C5DA5189448B0A387C@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <275EE7EE-E92C-454A-BD5C-C04BE171AA14@cs.columbia.edu> <4647_1371560112_51C058B0_4647_190_1_B5939C6860701C49AA39C5DA5189448B0A37D8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <010701ce6c35$672f6970$358e3c50$@shockey.us> In-Reply-To: <010701ce6c35$672f6970$358e3c50$@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.1] 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.18.152722 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] current draft 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, 18 Jun 2013 15:54:58 -0000 I agree, you may find exceptions in Europe as well more in the short number= category though (eg 118 series used as a brand), but they're just that, an= exception.=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Tuesday, June 18, 2013 5:06 PM To: FOUQUART Philippe OLNC/OLN; 'Henning Schulzrinne'; 'Peterson, Jon' Cc: stir@ietf.org; dcrocker@bbiw.net Subject: RE: [stir] current draft charter -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, June 18, 2013 8:55 AM To: Henning Schulzrinne; Peterson, Jon Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter FWIW, this notion of ownership of E.164 resources has indeed always been distinct of that of assignment. E.164 is actually governed by the overarching principles of E.190, which on this says that "assignment confers use of the resource but does not imply ownership by the assignee".=20 In numbering plans I'm familiar with, this principle translates into an article in all NRA assignment rulings stating that the assignment doesn't confer the right to protect a number as a trademark for instance. Or some limitations in time and transfer under conditions.=20 [RS> ]=20 [RS> ] In general you are right though there are some odd corner cases. Specifically the free phone number ranges 800 and 8XX ranges in the US and Canada. Although people sometimes like using ownership as a shortcut, it's more of a right of use really. (I'm sure some here will remember discussions on the notion of carrier of record with eye-watering nostalgia)=20 [RS> ] I wouldn't call it nostalgia, more a review of the battle scars and the cumulative effects of cranial concussion.=20 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 Henning Schulzrinne Sent: Tuesday, June 18, 2013 4:22 AM To: Peterson, Jon Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] current draft charter I've been trying diligently to avoid any ownership terminology - if they have any similarity to IP-related things, it's probably much more like IP addresses: you have to show need and you can't always take them with you. (For landline, it's *local* number portability. If you obtained a 212 number, you can't get a landline in LA with that number, at least at the moment. You can't request a specific number, even if it is available, etc.) On Jun 17, 2013, at 1:46 PM, Peterson, Jon wrote: >=20 > You may know more about number portability than me, but I don't agree=20 > with your assessment of it here. At best, I'd say that number=20 > portability in America allows consumers to choose which carrier "owns"=20 > a number. This is also a reason I keep putting scare quotes around=20 > "owns," because the assumptions of the DNS don't apply to users of=20 > telephone numbers, at least not in our current regulatory environment.=20 > If you are a registrant, you have the authority to configure your zone=20 > - that sounds close enough to be ownership to me (even though the UDRP=20 > or ICE can end your ownership under extreme conditions). If you have a=20 > telephone number assigned to you, a carrier still decides what number it rings. _______________________________________________ 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hadriel.kaplan@oracle.com Tue Jun 18 10:36: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 19DC621F9B1C for ; Tue, 18 Jun 2013 10:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 j3x35uSw+wsk for ; Tue, 18 Jun 2013 10:36:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6448B21F998F for ; Tue, 18 Jun 2013 10:36:30 -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 r5IHaIUv002602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jun 2013 17:36: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 r5IHaKaL000320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 17:36:20 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 r5IHaKgn011424; Tue, 18 Jun 2013 17:36:20 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jun 2013 10:36:19 -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, 18 Jun 2013 13:36:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 17:36:38 -0000 On Jun 17, 2013, at 8:47 PM, "Peterson, Jon" = wrote: >=20 > Definitely I agree that there needs to be a root here, at least at the > national level. A few people have commented that working from the = national > level makes more sense than trying to delegate something globally from = on > high. Choosing that scope could make it harder to guarantee your = vision of > a tariff-free identity, admittedly. I've name-dropped LoST a couple = times > here as a place to look for inspiration, perhaps. I read LoST a long time ago, and skimmed it again today, but I don't get = any inspiration relative to STIR. What dots am I supposed to be = connecting? No need for a long explanation, just some hints would be good. :) > But at the end of the day I was also envisioning that this revisited > identity system would still work for regular domain names per RFC4474, = and > that we'd probably even keep CID as an option for Identity-Info (or = its > successor). So I was anticipating there'd be diversity in the means by > which credentials could be indicated by Identity-Info, and that having = a > "root" wouldn't be exclusive in that there are identifiers other than > telephone numbers in the system too. Right, so I was thinking about that too, if we were to use a DNS-based = approach (or anything with a derived URL). I think that's still possible even for email-style names. For example, = when receiving a request from 'alice@foo.com' we could do a DNS lookup = for '_cid.foo.com' or some such pre-defined naming scheme, to get the = caller-id cert for 'foo.com'; or the RR for that DNS key could redirect = us to somewhere else if need be. Or we could do an HTTP automatically = for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where = the last part is a hash of the username. Or if we want the signer to be able to specify different certs for = different requests, we support including a small token that gets = appended to the automatic DNS or URL scheme for cert retrieval. For = example up to a 16-character token. The only reason to limit its size = would be to possibly get it (along with the signature and other info) = through PSTN links in a UUI or whatever, but if we don't care about that = for the email-style name cases then we could continue using the = Identity-Info header for that case. I recognize the nice property of = Identity-Info giving the URL was the cert could be hosted somewhere = else, separate from the From's domain. > So again, to the question of how golden the root is, I at least = pictured a > national-level root for telephone number identity that would, if at = all > possible, eliminate the problem of multiple trust anchors issuing > credentials for the same identity. Right so I think we're all on the same page for that then. :) > Just like the same cert could be > included by CID or referred to by HTTP, though, I imagine there could = be > more than one protocol for getting at those credentials. I'm ok with specifying multiple protocols for accessing it - I mean = that'll probably happen anyway (my company's products support half a = dozen different ones to access routing DBs, for example) - but I think = there needs to be one that's mandatory-to-implement, to get = interoperability. Even if we believe *only* carriers will be the ones = to query for STIR certs, many carriers buy products from multiple = vendors they need to interoperate. Even the ones that buy the SIP-based = equipment from only one vendor, often get the databases (or access to a = separately managed one) from someone else. > As for whether or not we need NPAC-style databases - agreed that here = we > don't need most of the data that's in them (like, LRNs aren't = obviously > material to solving our problem), but the authority structures they > reflect are absolutely integral to this. Ultimately, STIR proposes = only to > project onto the Internet the authority over numbers that is today > administered in those databases. Yup. As I said, it would help a heck of a lot to get this into the = NPAC-type databases. :) -hadriel From br@brianrosen.net Tue Jun 18 10:55: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 13CEA21F92B8 for ; Tue, 18 Jun 2013 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 RSFmHzZo+9PT for ; Tue, 18 Jun 2013 10:55:39 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0236321E8097 for ; Tue, 18 Jun 2013 10:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=/ZUkg5BFe6OCHRZnsn3qd4AnpFHXUzaGArHdCpS38OY=; b=KivrwQqBZnlVxVlPKrtuGYVOfX6c33He43ZGbaS8wCuHVnQhISifNMIM21iYX4mbEOBng2VOrFe8Gdv0mL1TkHBHNuO543w/K4QKy9SumvlYTX7w9oTM2GzymqNSj/vtnUp9GvgTkH6ah27KwFL9gDLcXUItf7HYY0+KtesJwdU=; Received: from [24.154.127.229] (port=39024 helo=[10.0.1.15]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Up080-0005N3-Kf; Tue, 18 Jun 2013 13:55:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> Date: Tue, 18 Jun 2013 13:55:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , "Peterson, Jon" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 17:55:44 -0000 > I read LoST a long time ago, and skimmed it again today, but I don't = get any inspiration relative to STIR. What dots am I supposed to be = connecting? > No need for a long explanation, just some hints would be good. :) LoST avoids a golden root by establishing a kind of transitive trust = model where an entity called a "Forest Guide" knows about other Forest = Guides and their coverage region by some unspecified means and can refer = a request for service in one of the known coverage regions to the proper = Forest Guide. Rather than having a root and a delegation model, it = relies on Forest Guide operators working out who should be trusted among = themselves.= From chris_wendt@cable.comcast.com Tue Jun 18 11:03: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 04C2621F961F for ; Tue, 18 Jun 2013 11:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 ozvfhKNApoG4 for ; Tue, 18 Jun 2013 11:03:26 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 160AB21F9AB2 for ; Tue, 18 Jun 2013 11:03:26 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.77966906; Tue, 18 Jun 2013 12:01:42 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.49]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 18 Jun 2013 14:02:12 -0400 From: "Wendt, Chris" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObE30wSlmpMZitUyhAdakrHC3YQ== Date: Tue, 18 Jun 2013 18:02:11 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD941224375@PACDCEXMB01.cable.comcast.com> References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> In-Reply-To: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <14054BFC2A7815409EBC7603F543D74E@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "Peterson, Jon" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 18:03:31 -0000 +1=20 We are very much on-board with the direction of this discussion, DNS lookup= is the way we would lean given vendor support for DNS/ENUM vs. HTTP. I th= ink there is also something to say for keeping a limited scope of DNS as a = good thing, vs. the infinite extensibility of HTTP. Does the current draft charter include this general direction as in scope? On Jun 18, 2013, at 1:36 PM, Hadriel Kaplan wro= te: >=20 > On Jun 17, 2013, at 8:47 PM, "Peterson, Jon" w= rote: >=20 >>=20 >> Definitely I agree that there needs to be a root here, at least at the >> national level. A few people have commented that working from the nation= al >> level makes more sense than trying to delegate something globally from o= n >> high. Choosing that scope could make it harder to guarantee your vision = of >> a tariff-free identity, admittedly. I've name-dropped LoST a couple time= s >> here as a place to look for inspiration, perhaps. >=20 > I read LoST a long time ago, and skimmed it again today, but I don't get = any inspiration relative to STIR. What dots am I supposed to be connecting= ? > No need for a long explanation, just some hints would be good. :) >=20 >=20 >> But at the end of the day I was also envisioning that this revisited >> identity system would still work for regular domain names per RFC4474, a= nd >> that we'd probably even keep CID as an option for Identity-Info (or its >> successor). So I was anticipating there'd be diversity in the means by >> which credentials could be indicated by Identity-Info, and that having a >> "root" wouldn't be exclusive in that there are identifiers other than >> telephone numbers in the system too. >=20 > Right, so I was thinking about that too, if we were to use a DNS-based ap= proach (or anything with a derived URL). >=20 > I think that's still possible even for email-style names. For example, w= hen receiving a request from 'alice@foo.com' we could do a DNS lookup for '= _cid.foo.com' or some such pre-defined naming scheme, to get the caller-id = cert for 'foo.com'; or the RR for that DNS key could redirect us to somewhe= re else if need be. Or we could do an HTTP automatically for 'http://foo.c= om/cid', or even 'http://foo.com/cid/ldkjhlashl' where the last part is a h= ash of the username. >=20 > Or if we want the signer to be able to specify different certs for differ= ent requests, we support including a small token that gets appended to the = automatic DNS or URL scheme for cert retrieval. For example up to a 16-cha= racter token. The only reason to limit its size would be to possibly get i= t (along with the signature and other info) through PSTN links in a UUI or = whatever, but if we don't care about that for the email-style name cases th= en we could continue using the Identity-Info header for that case. I recog= nize the nice property of Identity-Info giving the URL was the cert could b= e hosted somewhere else, separate from the From's domain. >=20 >=20 >> So again, to the question of how golden the root is, I at least pictured= a >> national-level root for telephone number identity that would, if at all >> possible, eliminate the problem of multiple trust anchors issuing >> credentials for the same identity. >=20 > Right so I think we're all on the same page for that then. :) >=20 >=20 >> Just like the same cert could be >> included by CID or referred to by HTTP, though, I imagine there could be >> more than one protocol for getting at those credentials. >=20 > I'm ok with specifying multiple protocols for accessing it - I mean that'= ll probably happen anyway (my company's products support half a dozen diffe= rent ones to access routing DBs, for example) - but I think there needs to = be one that's mandatory-to-implement, to get interoperability. Even if we = believe *only* carriers will be the ones to query for STIR certs, many carr= iers buy products from multiple vendors they need to interoperate. Even th= e ones that buy the SIP-based equipment from only one vendor, often get the= databases (or access to a separately managed one) from someone else. >=20 >=20 >> As for whether or not we need NPAC-style databases - agreed that here we >> don't need most of the data that's in them (like, LRNs aren't obviously >> material to solving our problem), but the authority structures they >> reflect are absolutely integral to this. Ultimately, STIR proposes only = to >> project onto the Internet the authority over numbers that is today >> administered in those databases. >=20 > Yup. As I said, it would help a heck of a lot to get this into the NPAC-= type databases. :) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Tue Jun 18 11:12: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 C652711E80F7 for ; Tue, 18 Jun 2013 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 bf9mLMjZGKH9 for ; Tue, 18 Jun 2013 11:12:12 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C70C411E80F6 for ; Tue, 18 Jun 2013 11:12:12 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 18 Jun 2013 11:12:12 -0700 From: Michael Hammer To: "br@brianrosen.net" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxSZyaUX2cyBk2/ZGQqej7gqJk3mvQAgAG9DwCAAJEBgIAADb2AgACwEACAABbBgIAAIr8AgAA+koCAARnqAIAABWGA//+PB8A= Date: Tue, 18 Jun 2013 18:12:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DE8A0@ex2k10mb2.corp.yaanatech.com> References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@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.200] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01C7_01CE6C2D.D2E4A110" MIME-Version: 1.0 Cc: "stir@ietf.org" , "jon.peterson@neustar.biz" , "hgs@cs.columbia.edu" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 18:12:24 -0000 ------=_NextPart_000_01C7_01CE6C2D.D2E4A110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But, I would modify that to have a Chief Forester (aka FCC) that points to the respective Forest Guides (aka SP number block holders) to resolve a query from the general public. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, June 18, 2013 1:56 PM To: Hadriel Kaplan Cc: stir@ietf.org; Peterson, Jon; Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases > I read LoST a long time ago, and skimmed it again today, but I don't get any inspiration relative to STIR. What dots am I supposed to be connecting? > No need for a long explanation, just some hints would be good. :) LoST avoids a golden root by establishing a kind of transitive trust model where an entity called a "Forest Guide" knows about other Forest Guides and their coverage region by some unspecified means and can refer a request for service in one of the known coverage regions to the proper Forest Guide. Rather than having a root and a delegation model, it relies on Forest Guide operators working out who should be trusted among themselves. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_01C7_01CE6C2D.D2E4A110 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx ODE4MTIxMFowIwYJKoZIhvcNAQkEMRYEFJWot1cyOmCEv8mQuTzxf+pTnbr/MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAPx5Ap4Xm7lOjTDRVVmub9+uiHstRbF1EicE4zONx ZyIB23fcO7Y0qBVsor1VczwSD35YOdMDmjm7wMgglDP+OhQqWcF7JlLnV8f87ciY1vEf8mvV86h2 +ZgtnhCJ9KlmV5zLb3YzrxIc25fsxSmJoIYF18jMIKNRRXvx+glT43trPySUEPp5QYF6Cr7MDxxy 88XOupMN4RkbpECDc/GVOgF6oBOVeb4DcNG0NahHEibr8vwkI3i2EBd5yHm2FZnYZCFr6VOY6leH /hYa7WFgcZvU5cs5qnSnNjrcQQmkaqKNt3y9w0wvYo/oHq/81sg+BS3Sn+hK6pL1MDfSqYQvewAA AAAAAA== ------=_NextPart_000_01C7_01CE6C2D.D2E4A110-- From hadriel.kaplan@oracle.com Tue Jun 18 11:54: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 15A1F11E80FA for ; Tue, 18 Jun 2013 11:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 zHVNpZhmMCul for ; Tue, 18 Jun 2013 11:54:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86B11E80F9 for ; Tue, 18 Jun 2013 11:54:15 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5IIs3X2028284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jun 2013 18:54:05 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 r5IIs25F026796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 18:54:03 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 r5IIs2HM029217; Tue, 18 Jun 2013 18:54:02 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-165-127.vpn.oracle.com (/10.154.165.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jun 2013 11:54: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: Date: Tue, 18 Jun 2013 14:54:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E833ABD-793F-4E0E-9F8E-793BC23DF26F@oracle.com> References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@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" , "Peterson, Jon" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 18:54:21 -0000 We already have a transitive-trust of model for caller-id: = P-Asserted-Identity. It's the lack of faith in transitive-trust that brought us here, isn't = it? -hadriel On Jun 18, 2013, at 1:55 PM, Brian Rosen wrote: >> I read LoST a long time ago, and skimmed it again today, but I don't = get any inspiration relative to STIR. What dots am I supposed to be = connecting? >> No need for a long explanation, just some hints would be good. :) > LoST avoids a golden root by establishing a kind of transitive trust = model where an entity called a "Forest Guide" knows about other Forest = Guides and their coverage region by some unspecified means and can refer = a request for service in one of the known coverage regions to the proper = Forest Guide. Rather than having a root and a delegation model, it = relies on Forest Guide operators working out who should be trusted among = themselves. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Tue Jun 18 12:26: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 54EB821E80B6 for ; Tue, 18 Jun 2013 12:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 sqR+YhlmoSaF for ; Tue, 18 Jun 2013 12:26:54 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 44BE211E80F6 for ; Tue, 18 Jun 2013 12:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371583501; x=1686936440; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=4I/+rZH7KW qvaYRxgbAyZ1pPY7rZYb7yhL66rrneYiA=; b=pW3wFbPPlp+RUQx48fWAHXxxzx TjsaJg7+OSVU7YjSFNYc3Q7PivEjjXTm+L6VzYCJhPM4ajqytbT+BAtTJ0rw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19688198; Tue, 18 Jun 2013 15:25:00 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 15:26:38 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKAgAElawD//6FkgIAAmBwA///JN4AAMejCAAAArByAAAIK4QD//5PAAA== Date: Tue, 18 Jun 2013 19:26:38 +0000 Message-ID: In-Reply-To: <9E833ABD-793F-4E0E-9F8E-793BC23DF26F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 1nbNr6GMDk6MMRsB3uCMlg== Content-Type: text/plain; charset="us-ascii" Content-ID: <68276FDFDB136045B7F469AD3C1F3557@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 19:26:58 -0000 I wouldn't characterize it as transitive trust in that sense, no. Think about it like a whole nation-state is under a tree, and you ask your local Forest Guide if you need to find the tree of another nation-state. It's a way to let non-overlapping authorities opt in to cooperating on a global system. So yes, you trust your own tree to be able to point you to other trees as a form of lateral delegation, as an alternative to top-down. But within the +1 tree, for example, there is a direct delegation of authority.=20 Jon Peterson Neustar, Inc. On 6/18/13 11:54 AM, "Hadriel Kaplan" wrote: > >We already have a transitive-trust of model for caller-id: >P-Asserted-Identity. >It's the lack of faith in transitive-trust that brought us here, isn't it? > >-hadriel > > >On Jun 18, 2013, at 1:55 PM, Brian Rosen wrote: > >>> I read LoST a long time ago, and skimmed it again today, but I don't >>>get any inspiration relative to STIR. What dots am I supposed to be >>>connecting? >>> No need for a long explanation, just some hints would be good. :) >> LoST avoids a golden root by establishing a kind of transitive trust >>model where an entity called a "Forest Guide" knows about other Forest >>Guides and their coverage region by some unspecified means and can refer >>a request for service in one of the known coverage regions to the proper >>Forest Guide. Rather than having a root and a delegation model, it >>relies on Forest Guide operators working out who should be trusted among >>themselves. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From dhc@dcrocker.net Tue Jun 18 12: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 BD9F021E80B2 for ; Tue, 18 Jun 2013 12:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3CMuT4mjT5g for ; Tue, 18 Jun 2013 12:36:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D5CB421E80A8 for ; Tue, 18 Jun 2013 12:36:49 -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 r5IJaZPb026979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jun 2013 12:36:39 -0700 Message-ID: <51C0B6B4.7030806@dcrocker.net> Date: Tue, 18 Jun 2013 12:36:20 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 18 Jun 2013 12:36:39 -0700 (PDT) Cc: "stir@ietf.org" , Henning Schulzrinne , Hadriel Kaplan , Brian Rosen Subject: Re: [stir] current draft charter - ENUM and databases 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, 18 Jun 2013 19:36:54 -0000 On 6/18/2013 12:26 PM, Peterson, Jon wrote: >So yes, you trust your own tree to be able to point you to other > trees as a form of lateral delegation, as an alternative to top-down. Huh? How is this not a transitive trust model? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard@shockey.us Tue Jun 18 12:39: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 4C95421E8088 for ; Tue, 18 Jun 2013 12:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.277, 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 0SOQTHy7gcga for ; Tue, 18 Jun 2013 12:38:58 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 6F34721E8050 for ; Tue, 18 Jun 2013 12:38:58 -0700 (PDT) Received: (qmail 8624 invoked by uid 0); 18 Jun 2013 19:38:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 18 Jun 2013 19:38:35 -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=l59jMxFuHClQ3YqSYYvZTr4rlzmGxVQzmElp9qJp59s=; b=PSpyD3+K+n2kfE2oLkGN9/NBpelV3K2AQELLVjUSbhwde28zuwTh7yGXL6ifg37LCfjXN/eQE5eFmwgeCOe5Pa6lB7Cu4gwnmAMdiecikOJq6qWGAawnPKa1vd/R4qcW; Received: from [72.66.111.124] (port=54744 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Up1jf-0006ai-EO; Tue, 18 Jun 2013 13:38:35 -0600 From: "Richard Shockey" To: "'Peterson, Jon'" , References: <9E833ABD-793F-4E0E-9F8E-793BC23DF26F@oracle.com> In-Reply-To: Date: Tue, 18 Jun 2013 15:38:33 -0400 Message-ID: <021b01ce6c5b$6bea1610$43be4230$@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: AQFpePInm6JXQ8CKtZ/8VvQIXoNCD5oFw/8w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 19:39:03 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Tuesday, June 18, 2013 3:27 PM To: Hadriel Kaplan; Brian Rosen Cc: stir@ietf.org; Henning Schulzrinne Subject: Re: [stir] current draft charter - ENUM and databases I wouldn't characterize it as transitive trust in that sense, no. Think about it like a whole nation-state is under a tree, and you ask your local Forest Guide if you need to find the tree of another nation-state. It's a way to let non-overlapping authorities opt in to cooperating on a global system. So yes, you trust your own tree to be able to point you to other trees as a form of lateral delegation, as an alternative to top-down. But within the +1 tree, for example, there is a direct delegation of authority. [RS> ] Sort of .. The North American Numbering Plan (NANP) is an integrated telephone numbering plan serving 20 North American countries that share its resources. These countries include the United States and its territories, Canada, Bermuda, Anguilla, Antigua & Barbuda, the Bahamas, Barbados, the British Virgin Islands, the Cayman Islands, Dominica, the Dominican Republic, Grenada, Jamaica, Montserrat, St. Maarten, St. Kitts and Nevis, St. Lucia, St. Vincent and the Grenadines, Trinidad and Tobago, and Turks & Caicos. Jon Peterson Neustar, Inc. On 6/18/13 11:54 AM, "Hadriel Kaplan" wrote: > >We already have a transitive-trust of model for caller-id: >P-Asserted-Identity. >It's the lack of faith in transitive-trust that brought us here, isn't it? > >-hadriel > > >On Jun 18, 2013, at 1:55 PM, Brian Rosen wrote: > >>> I read LoST a long time ago, and skimmed it again today, but I don't >>>get any inspiration relative to STIR. What dots am I supposed to be >>>connecting? >>> No need for a long explanation, just some hints would be good. :) >> LoST avoids a golden root by establishing a kind of transitive trust >>model where an entity called a "Forest Guide" knows about other Forest >>Guides and their coverage region by some unspecified means and can >>refer a request for service in one of the known coverage regions to >>the proper Forest Guide. Rather than having a root and a delegation >>model, it relies on Forest Guide operators working out who should be >>trusted among themselves. >> _______________________________________________ >> 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 Jun 18 12:54: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 CB3D321F9A1F for ; Tue, 18 Jun 2013 12:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 sqONsS0kqU9o for ; Tue, 18 Jun 2013 12:54:55 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id B53E221F9A03 for ; Tue, 18 Jun 2013 12:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371585233; x=1686940031; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=RAn+WmtWPH RlqCtPKwdK3383nIoAZ6q6JcnDnyln/30=; b=CAL0KhLoFXJ+bWqlG4w4axdrxe mC4UZWazAHXCbZKl7N/GfqfRukuKUiI+qUzcFV3T997tcSRnXGO8eCdzBHww== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21129881; Tue, 18 Jun 2013 15:53:52 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 15:54:37 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKAgAElawD//6FkgIAAmBwA///JN4AAMejCAAAArByAAAIK4QD//5PAAIAAeBEA//+PwYA= Date: Tue, 18 Jun 2013 19:54:37 +0000 Message-ID: In-Reply-To: <51C0B6B4.7030806@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: M7mwNhmOZ7aHBVzIKyETOA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne , Hadriel Kaplan , Brian Rosen Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 19:54:59 -0000 I'm not saying that you don't trust your Forest Guide to find you other trees, but I don't think it is an apples-to-apples comparison to suggest this is comparable to the transitive trust we see in SS7 signaling and in PAI.=20 And Mr. Shockey your point is well taken that "nation-state" was imprecise there. Jon Peterson Neustar, Inc. On 6/18/13 12:36 PM, "Dave Crocker" wrote: >On 6/18/2013 12:26 PM, Peterson, Jon wrote: >>So yes, you trust your own tree to be able to point you to other >> trees as a form of lateral delegation, as an alternative to top-down. > > >Huh? How is this not a transitive trust model? > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From hgs@cs.columbia.edu Tue Jun 18 15:29: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 33E5211E811A for ; Tue, 18 Jun 2013 15:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 pXgGOy2tRpn3 for ; Tue, 18 Jun 2013 15:29:12 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6974311E8117 for ; Tue, 18 Jun 2013 15:29:12 -0700 (PDT) Received: from [172.20.27.174] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5IMTAoJ012308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Jun 2013 18:29:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Henning Schulzrinne In-Reply-To: <9E833ABD-793F-4E0E-9F8E-793BC23DF26F@oracle.com> Date: Tue, 18 Jun 2013 18:29:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> <9E833ABD-793F-4E0E-9F8E-793BC23DF26F@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "stir@ietf.org" , "Peterson, Jon" , Brian Rosen Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 18 Jun 2013 22:29:17 -0000 Having been involved in LoST, this isn't quite the same as the PAI = "transitive trust". In this particular case, NRA or number assignment = authorities would announce their coverage regions, and maybe additional = information, such as entry points into DNS or data stores. Each entity = would only have to trust announcements, presumably signed, that it = likes, rather than receiver of information D trusting that A, B and C on = the call path are trustworthy and didn't mangle or fake the information, = as in PAI. I don't think there's much of an issue with number allocators trusting = each other, compared to trusting a random carrier the recipient has = never heard of. Thus, I'd avoid the use of the term "transitive" trust here. Henning On Jun 18, 2013, at 2:54 PM, Hadriel Kaplan = wrote: >=20 > We already have a transitive-trust of model for caller-id: = P-Asserted-Identity. > It's the lack of faith in transitive-trust that brought us here, isn't = it? >=20 > -hadriel >=20 >=20 > On Jun 18, 2013, at 1:55 PM, Brian Rosen wrote: >=20 >>> I read LoST a long time ago, and skimmed it again today, but I don't = get any inspiration relative to STIR. What dots am I supposed to be = connecting? >>> No need for a long explanation, just some hints would be good. :) >> LoST avoids a golden root by establishing a kind of transitive trust = model where an entity called a "Forest Guide" knows about other Forest = Guides and their coverage region by some unspecified means and can refer = a request for service in one of the known coverage regions to the proper = Forest Guide. Rather than having a root and a delegation model, it = relies on Forest Guide operators working out who should be trusted among = themselves. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 From yiu_lee@cable.comcast.com Wed Jun 19 06:14: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 4A8A221F9C2B for ; Wed, 19 Jun 2013 06:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 NsG2j0lazBKD for ; Wed, 19 Jun 2013 06:14:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7227721F9C25 for ; Wed, 19 Jun 2013 06:14:37 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78104272; Wed, 19 Jun 2013 07:14:01 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 09:14:34 -0400 From: "Lee, Yiu" To: "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObO7wwSlmpMZitUyhAdakrHC3YQ== Date: Wed, 19 Jun 2013 13:14:32 +0000 Message-ID: In-Reply-To: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.248] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3454478071_12636" MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 13:14:43 -0000 --B_3454478071_12636 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I am on board using dns for lookup. One question in your example: When you receive alice@foo.com, how do you derive it to "_cid.foo.com"? Do you suggest _cid is the tn or some other identifier? On 6/18/13 1:36 PM, "Hadriel Kaplan" wrote: >I think that's still possible even for email-style names. For example, >when receiving a request from'alice@foo.com' we could do a DNS lookup for >'_cid.foo.com' or some such pre-defined naming scheme, to get the >caller-id cert for 'foo.com'; or the RR for that DNS key could redirect >us to somewhere else if need be. Or we could do an HTTP automatically >for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where >the last part is a hash of the username. --B_3454478071_12636 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFOuY ei6Ux55niJPqGqe37fYtHv0CMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYxOTEzMTQzMFowDQYJKoZIhvcNAQEBBQAEggEAdrvSIjnhfEmadUpz5Ehd h5NxTU7M0G8qeZMgMzNehOvA1SjpXhurKNoon/t5C70wZ6ODqdWfreB3bDx4bV5mZO5akGlL oC5o/q6Oc5OEJPBBjL8r5U1H/DrDAL546kgSx9ZdKk67n4he7SC26F5YJwEbVA7Xj9RbTHp0 NSQn/8ejjIR+kImR0/8l5rJsGTLKEEqZoKE0qw3QarnkJnisnLhPG9iT+XOz9igm1K2aszM6 zZ1KCHlw6za+mbFfadEMqP72yK7GjFUcvbQJnZd1TZ6hO8sjh263TH/GHNiSWDqG8vdU8wuR gvJeqGt4cQxL2pYIeV3XTVcSA3gWs8rjRw== --B_3454478071_12636-- From michael.hammer@yaanatech.com Wed Jun 19 06:37: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 2799F21F9BD3 for ; Wed, 19 Jun 2013 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 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 sqpCWdC-ykTg for ; Wed, 19 Jun 2013 06:37: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 B735321F91A5 for ; Wed, 19 Jun 2013 06:37:07 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 19 Jun 2013 06:37:06 -0700 From: Michael Hammer To: "Yiu_Lee@Cable.Comcast.com" , "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxSZyaUX2cyBk2/ZGQqej7gqJk3mvQAgAG9DwCAAJEBgIAADb2AgACwEACAABbBgIAAIr8AgAA+koCAARnqAIABSTIA//+PwLA= Date: Wed, 19 Jun 2013 13:37:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DEDDE@ex2k10mb2.corp.yaanatech.com> References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@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.216] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006F_01CE6CD0.8EB643B0" MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 13:37:12 -0000 ------=_NextPart_000_006F_01CE6CD0.8EB643B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is that out of scope? Should we focus on E.164 first, email-style names second, and the interworking of the two third? That wouldn't preclude reuse of solution to one for the other, or thinking about that in advance. But, we are talking about two different authority delegation trees here and I am not sure if you want one constrained by solutions for the other. If we do, then at least make it clear that is a decision being made. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Wednesday, June 19, 2013 9:15 AM To: stir@ietf.org Subject: Re: [stir] current draft charter - ENUM and databases I am on board using dns for lookup. One question in your example: When you receive alice@foo.com, how do you derive it to "_cid.foo.com"? Do you suggest _cid is the tn or some other identifier? On 6/18/13 1:36 PM, "Hadriel Kaplan" wrote: >I think that's still possible even for email-style names. For example, >when receiving a request from'alice@foo.com' we could do a DNS lookup >for '_cid.foo.com' or some such pre-defined naming scheme, to get the >caller-id cert for 'foo.com'; or the RR for that DNS key could redirect >us to somewhere else if need be. Or we could do an HTTP automatically >for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where >the last part is a hash of the username. ------=_NextPart_000_006F_01CE6CD0.8EB643B0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx OTEzMzcwNFowIwYJKoZIhvcNAQkEMRYEFFr2QjNKjVPPZvTLfxs8uAPJlQD6MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAKAJ+wcjCL82hmN66ibe2c+yDDPz3JhFc+cS53/Vk bUUiSqjOFdBUoJAugXvXmLOYwCyvCKrb5hBLlzEZioq79zaDa1q6kZQA8F1DpzolGZro+3SCpIYd yn96y2WEi0JLkIqtLx2LvbL6sktxYHYjliDxTIIPQMVYlQNJVel7pg+F5fxCQ1Kqc3g+45u6dKz+ nQtIZ3ovwt0gWhIVX20ILP6YSD4K1cI883Sv1Wtki9o7wMpKb1J9ncTV6EJQcZ/P4Ns6EE/yEQ7U cI3tpzzKQdaO77/LpG4IEfWD0Yr0m9YQKgMb4fuFDa+uf7F8wjPaAK4frz/5O/fhXaVbKwctpQAA AAAAAA== ------=_NextPart_000_006F_01CE6CD0.8EB643B0-- From dhc@dcrocker.net Wed Jun 19 06:41: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 1830621F9A12 for ; Wed, 19 Jun 2013 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 5T9l4L23aKzO for ; Wed, 19 Jun 2013 06:41:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26E9521F91A5 for ; Wed, 19 Jun 2013 06:41:12 -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 r5JDf8Sp016652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 06:41:11 -0700 Message-ID: <51C1B4E3.6080209@dcrocker.net> Date: Wed, 19 Jun 2013 06:40:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Hammer References: <8C77C05D-6ED2-4429-BF1C-72082F4ADE76@oracle.com> <00C069FD01E0324C9FFCADF539701DB3A03DEDDE@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DEDDE@ex2k10mb2.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]); Wed, 19 Jun 2013 06:41:12 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] current draft charter - ENUM and databases 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, 19 Jun 2013 13:41:17 -0000 On 6/19/2013 6:37 AM, Michael Hammer wrote: > Should we focus on E.164 first, email-style names second, and the > interworking of the two third? That does sound pragmatic, doesn't it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Wed Jun 19 06:53: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 078C521F9B41 for ; Wed, 19 Jun 2013 06:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 buB6I5tnh11a for ; Wed, 19 Jun 2013 06:53:04 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id AB9AA21F9C68 for ; Wed, 19 Jun 2013 06:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371650113; x=1686983425; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=EeOlyEcqwZ ZT+DLTW4W8+x/nVjDq8aSMGkGZw6xP1zg=; b=KLVSPNgwngSq51BbjbdnWKRdD4 84GUuMGohAEdleyltxCK5kqQh2ATrsJ+0zDxETIjiOgGJGDcPom0UlOOmWlg== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25359817; Wed, 19 Jun 2013 09:55:12 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 09:52:10 -0400 From: "Rosen, Brian" To: "stir@ietf.org" Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMg== Date: Wed, 19 Jun 2013 13:52:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: mgonepYjfyWsjNeaTkd2lA== Content-Type: text/plain; charset="us-ascii" Content-ID: <396D5132AE749642B4E1D7003BB74913@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 13:53:09 -0000 A lot of our discussion is focussed on where certs are found. I want to ma= ke sure that we agree on the basics, because where certs are found is prett= y far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE = of the call, because we believe that spoofing identity or non providing ide= ntity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sig= n or encrypt it in a way that a downstream entity can verify that the infor= mation is valid 4. The CREDENTIALS we're going to use, for identities that are telephone nu= mbers, is based on delegation of the number, rooted in the national numberi= ng authority. For identities that are domain based, the credentials are ba= sed on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the origi= nating device or service provider signing information and carries the signa= ture in the signaling. The other is some out of band mechanism that involv= es some new database or service that gets written by the originating device= or service provider and checked by some downstream entity. The latter mec= hanism is needed to allow the identity to be assured even if the informatio= n or signature from the in band mechanism is lost (such as when the call go= es through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what= the out of band mechanism does. So, I ask, do you agree with that? Brian= From pp3129@att.com Wed Jun 19 07:05: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 E01EA21F8F0C for ; Wed, 19 Jun 2013 07:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 qNJoVJos+hKJ for ; Wed, 19 Jun 2013 07:05:49 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD021F8ECB for ; Wed, 19 Jun 2013 07:05:48 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id cbab1c15.0.788257.00-217.2194470.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 19 Jun 2013 14:05:48 +0000 (UTC) X-MXL-Hash: 51c1babc72c55de1-e910292b89e3a867d17031f165b92f106ccbeb4c 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 r5JE5lVL012564; Wed, 19 Jun 2013 10:05:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5JE5e96012463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 10:05:44 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 19 Jun 2013 14:05:29 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:05:35 -0400 From: "PFAUTZ, PENN L" To: "Rosen, Brian" , "stir@ietf.org" Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+Ag Date: Wed, 19 Jun 2013 14:05:34 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> References: 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: 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=Ee9/toaC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=vt7402L8E50A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ocOsavY7rbkA:10 a=48vgC7mUAAAA:8 a=GXxXZcS7crhRFf] X-AnalysisOut: [4OWg4A:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=eKjnI_QlbYtlomxH:21 a=-oRx6sAvQLmJO1TB:21] Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:05:55 -0000 Brian: I think this is a helpful summary to keep us on track; thanks for posting i= t. I do wonder if the fifth point, about handling SS7 in the middle may be = too ambitious. My own belief is that the best we can hope to achieve is a s= olution in the post PSTN transition where we are end-to-end IP. While there= is SS7 in the middle, there will still likely be SS7 at the beginning or a= t the end of some calls and I don't see us fixing those cases. So, I'll be = happy if we just get the promised land right. 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 Ros= en, Brian Sent: Wednesday, June 19, 2013 9:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to ma= ke sure that we agree on the basics, because where certs are found is prett= y far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE = of the call, because we believe that spoofing identity or non providing ide= ntity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sig= n or encrypt it in a way that a downstream entity can verify that the infor= mation is valid 4. The CREDENTIALS we're going to use, for identities that are telephone nu= mbers, is based on delegation of the number, rooted in the national numberi= ng authority. For identities that are domain based, the credentials are ba= sed on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the origi= nating device or service provider signing information and carries the signa= ture in the signaling. The other is some out of band mechanism that involv= es some new database or service that gets written by the originating device= or service provider and checked by some downstream entity. The latter mec= hanism is needed to allow the identity to be assured even if the informatio= n or signature from the in band mechanism is lost (such as when the call go= es through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what= the out of band mechanism does. So, I ask, do you agree with that? Brian _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From oej@edvina.net Wed Jun 19 07:12: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 9378021F9BB5 for ; Wed, 19 Jun 2013 07:12:23 -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=[AWL=0.000, 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 sqvkgIuiieaQ for ; Wed, 19 Jun 2013 07:12:23 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C0BBE21F9B9A for ; Wed, 19 Jun 2013 07:12:22 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DF49793C1AF; Wed, 19 Jun 2013 14:12:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 19 Jun 2013 16:12:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1503) Cc: "stir@ietf.org" , "Olle E. Johansson" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:12:23 -0000 19 jun 2013 kl. 15:52 skrev "Rosen, Brian" : > A lot of our discussion is focussed on where certs are found. I want = to make sure that we agree on the basics, because where certs are found = is pretty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting > 2. The APPROACH we're going to use is to verify the IDENTITY of the = SOURCE of the call, because we believe that spoofing identity or non = providing identity is the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call = and sign or encrypt it in a way that a downstream entity can verify that = the information is valid > 4. The CREDENTIALS we're going to use, for identities that are = telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the = originating device or service provider signing information and carries = the signature in the signaling. The other is some out of band mechanism = that involves some new database or service that gets written by the = originating device or service provider and checked by some downstream = entity. The latter mechanism is needed to allow the identity to be = assured even if the information or signature from the in band mechanism = is lost (such as when the call goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or = what the out of band mechanism does. >=20 > So, I ask, do you agree with that? I think we should declare "identities that are domain based" out of = scope for this work.=20 #5 can also be useful with old b2buas that will drop a lot of headers = mid-call. /O= From michael.hammer@yaanatech.com Wed Jun 19 07:18: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 492BD21F9C1E for ; Wed, 19 Jun 2013 07:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-1.776, 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 TjBWnKb6DVSW for ; Wed, 19 Jun 2013 07:18:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id A939C21F9C19 for ; Wed, 19 Jun 2013 07:18:45 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 19 Jun 2013 07:18:45 -0700 From: Michael Hammer To: "pp3129@att.com" , "Brian.Rosen@neustar.biz" , "stir@ietf.org" Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlA= Date: Wed, 19 Jun 2013 14:18:43 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60495F251@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.216] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0074_01CE6CD6.601122E0" MIME-Version: 1.0 Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:18:57 -0000 ------=_NextPart_000_0074_01CE6CD6.601122E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The question of whether this works with SS7 in the path is a key one. That was part of the reason I was concerned about doing both E.164 and email identities at the same time. I am not buying the out-of-band, not connected to the current state of the received signaling message, yet. If the signaling message arrives with different elements, how do I know that it is the same thing that is being signed out of band? Versus an imposter? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, June 19, 2013 10:06 AM To: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? Brian: I think this is a helpful summary to keep us on track; thanks for posting it. I do wonder if the fifth point, about handling SS7 in the middle may be too ambitious. My own belief is that the best we can hope to achieve is a solution in the post PSTN transition where we are end-to-end IP. While there is SS7 in the middle, there will still likely be SS7 at the beginning or at the end of some calls and I don't see us fixing those cases. So, I'll be happy if we just get the promised land right. 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 Rosen, Brian Sent: Wednesday, June 19, 2013 9:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. So, I ask, do you agree with that? 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 ------=_NextPart_000_0074_01CE6CD6.601122E0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx OTE0MTg0M1owIwYJKoZIhvcNAQkEMRYEFKKjCpPVyfbI/uI4z6xZQWEo9aP0MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAdjfAomI10DiFhJCPAbcHBjr1kYdYsCtqIb0TmvlZ dm6Tu/FwPScU2KzlqFTc4mgBXr2SQk3lY3bN4JgBq/DUrME+lpePVsZvgqtwl7YPERg1gS4LId3G N84h++MQqaWYk6TaH5mKLb16/Ek9eRRak7JzdS4mPAe9ZA3ONH2K9hivsvIVYXcK3tiCWVuhBAY9 2DMU3FBw8YioVHX0zdz0Et1K8p0YEiWlf/aB/bnJfa0aPxWrW3uFsS+x0YArQzrX/cNuXUNe9fx2 O5THLIxqg9rkelOFoGM1svc2zJYIOKakPBe2gDZkT3lQOF+94YvpOJCZaSOFg/xL3KSJ0WsgywAA AAAAAA== ------=_NextPart_000_0074_01CE6CD6.601122E0-- From brian.rosen@neustar.biz Wed Jun 19 07:19: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 3759421F9C23 for ; Wed, 19 Jun 2013 07:19: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 IgmudYMgnTEJ for ; Wed, 19 Jun 2013 07:19:08 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2335121F9C19 for ; Wed, 19 Jun 2013 07:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371651726; x=1687010423; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=hMCL1CqJN5 SQC8tyfIIodmD9hP2DRvMNJAnUbsJiiAg=; b=PsQfTTO2I1NUUsMQ2COdhekw9V E1aYAiKgXEt682RC1oRzV0XEcMFsgc0hiqFA96huFRF+HkTupFd3H2VekRzw== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25361523; Wed, 19 Jun 2013 10:22:05 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:19:00 -0400 From: "Rosen, Brian" To: "PFAUTZ, PENN L" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggABJJoA= Date: Wed, 19 Jun 2013 14:18:59 +0000 Message-ID: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ZwkzTXmE9TqN19NmaSo+ug== Content-Type: text/plain; charset="us-ascii" Content-ID: <5AC0BFB4B33B6047A5CD333793674EDC@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:19:12 -0000 I think that the in band mechanism comes first. If we can agree on an out = of band mechanism we think we can deploy before the problem goes away, that= would be good. That means our milestones should show work on the out of b= and mechanism later. I observe that there are a lot of cases of SIP - SS7 - SIP. Some have clai= med that by the time we could deploy any solution, that middle SS7 hop will= be gone. I'm not so sure of that. Brian On Jun 19, 2013, at 10:05 AM, "PFAUTZ, PENN L" wrote: > Brian: > I think this is a helpful summary to keep us on track; thanks for posting= it. I do wonder if the fifth point, about handling SS7 in the middle may b= e too ambitious. My own belief is that the best we can hope to achieve is a= solution in the post PSTN transition where we are end-to-end IP. While the= re is SS7 in the middle, there will still likely be SS7 at the beginning or= at the end of some calls and I don't see us fixing those cases. So, I'll b= e happy if we just get the promised land right. >=20 > 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 R= osen, Brian > Sent: Wednesday, June 19, 2013 9:52 AM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to = make sure that we agree on the basics, because where certs are found is pre= tty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting > 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURC= E of the call, because we believe that spoofing identity or non providing i= dentity is the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign or encrypt it in a way that a downstream entity can verify that the inf= ormation is valid > 4. The CREDENTIALS we're going to use, for identities that are telephone = numbers, is based on delegation of the number, rooted in the national numbe= ring authority. For identities that are domain based, the credentials are = based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the ori= ginating device or service provider signing information and carries the sig= nature in the signaling. The other is some out of band mechanism that invo= lves some new database or service that gets written by the originating devi= ce or service provider and checked by some downstream entity. The latter m= echanism is needed to allow the identity to be assured even if the informat= ion or signature from the in band mechanism is lost (such as when the call = goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > 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 dhc@dcrocker.net Wed Jun 19 07: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 75C2121F9C02 for ; Wed, 19 Jun 2013 07:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 aiTrNIxmOi6v for ; Wed, 19 Jun 2013 07:22:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8516221F9C03 for ; Wed, 19 Jun 2013 07:22:43 -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 r5JEMei8017459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 07:22:43 -0700 Message-ID: <51C1BE9B.4090807@dcrocker.net> Date: Wed, 19 Jun 2013 07:22:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" 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]); Wed, 19 Jun 2013 07:22:43 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? 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, 19 Jun 2013 14:22:48 -0000 On 6/19/2013 6:52 AM, Rosen, Brian wrote: > 5. We think we need two MECHANISMS, an in-band mechanism that has the > originating device or service provider signing information and > carries the signature in the signaling. The other is some out of > band mechanism that involves some new database or service that gets > written by the originating device or service provider and checked by > some downstream entity. The latter mechanism is needed to allow the > identity to be assured even if the information or signature from the > in band mechanism is lost (such as when the call goes through an SS7 > hop). Good list. I'd like us to explore #5 carefully. Although it carries the usual appeal of flexibility. However beyon that intuitive appeal, it dramatically increases complexity and its viable usage is not at all obvious. The motivating rationale in the last sentence sounds great, but that doesn't mean it's viable. Some examples of questions that such an approach needs to answer: 1. What does it do to overall design and operations complexity and cost? 2. What is a realistic estimate of the likelihood of major benefit; in other words, why should we believe it will help enough to warrant the added costs? 3. What are the added adoption barriers? 4. What are the early-stage costs, such as when almost no one has it implemented? For example, the stated use is when the call request arrives without the signature information; this will look exactly the same as a call from a system that did not add the signature. Initially the latter will be far, far more common than the former. Almost no one will be signing. Hence, the querying agent is going to be making unsuccessful alternative checks essentially every time. Failure rates at that level discourage adoption. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Wed Jun 19 07:35: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 9E24521F9C35 for ; Wed, 19 Jun 2013 07:35:09 -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 anvV9m5HVqXk for ; Wed, 19 Jun 2013 07:35:05 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 760C121F9C47 for ; Wed, 19 Jun 2013 07:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371652684; x=1687010423; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=/RZB5fyC26 4OHgvU82ZHTDJcstRqW6y5JrjtRIxdCVU=; b=rU+O/gmcI0yX5maOq3kfQhQ95J KT2hjo2nN4hVy7DOvwE1/2cvTPw9nI4OAxhfVFDOcNnnTTw2NsPO1B8KlN2w== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25362673; Wed, 19 Jun 2013 10:38:03 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:34:59 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlCAAEiZgA== Date: Wed, 19 Jun 2013 14:34:59 +0000 Message-ID: <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: aKSqeJ+H5YC6IwGqhXEMaA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "pp3129@att.com" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:35:09 -0000 Of course, like most of us, you are an engineer, so you want to see that th= ere is at least one solution that could work before you even want to see so= mething in a charter. So, EKR proposed one solution where the source write= s a data record in a database encrypted for the termination. All that depe= nds on is the source and destination identities. Ignoring whether you thin= k we can deploy it, it does solve the problem. I'll give you the guts of another solution: The SIP-> SS7 GW writes a reco= rd with Called and Calling party TNs, and the SIP headers. The SS7-SIP GW = searches for a record with the same called and calling TNs, within a short = time frame, and retrieves the SIP headers, which it uses to populate its ou= tgoing message, effectively restoring the signature and the elements that w= ere used when creating it. Ignoring whether you think we could deploy it, = it also solves the problem, but only in a more restricted set of situations= . There are all sorts of trust issues, cert distribution issues, privacy issu= es, business model issues, and a host of other stuff, but either of these s= olutions would work. In this thread, I'd like to stay away from discussing= those issues - I'm only trying to convince you that there are reasonable e= ngineering solutions that would work. Once we have a WG, we can work out t= he issues. In the end, that might fail, but we're starting from reasonabl= e engineering base I think. Brian On Jun 19, 2013, at 10:18 AM, Michael Hammer = wrote: > The question of whether this works with SS7 in the path is a key one. > That was part of the reason I was concerned about doing both E.164 and em= ail > identities at the same time. >=20 > I am not buying the out-of-band, not connected to the current state of th= e > received signaling message, yet. > If the signaling message arrives with different elements, how do I know t= hat > it is the same thing that is being signed out of band? > Versus an imposter? >=20 > Mike >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > PFAUTZ, PENN L > Sent: Wednesday, June 19, 2013 10:06 AM > To: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? >=20 > Brian: > I think this is a helpful summary to keep us on track; thanks for posting > it. I do wonder if the fifth point, about handling SS7 in the middle may = be > too ambitious. My own belief is that the best we can hope to achieve is a > solution in the post PSTN transition where we are end-to-end IP. While th= ere > is SS7 in the middle, there will still likely be SS7 at the beginning or = at > the end of some calls and I don't see us fixing those cases. So, I'll be > happy if we just get the promised land right. >=20 > 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 > Rosen, Brian > Sent: Wednesday, June 19, 2013 9:52 AM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to > make sure that we agree on the basics, because where certs are found is > pretty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The > APPROACH we're going to use is to verify the IDENTITY of the SOURCE of th= e > call, because we believe that spoofing identity or non providing identity= is > the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign > or encrypt it in a way that a downstream entity can verify that the > information is valid 4. The CREDENTIALS we're going to use, for identitie= s > that are telephone numbers, is based on delegation of the number, rooted = in > the national numbering authority. For identities that are domain based, = the > credentials are based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the > originating device or service provider signing information and carries th= e > signature in the signaling. The other is some out of band mechanism that > involves some new database or service that gets written by the originatin= g > device or service provider and checked by some downstream entity. The > latter mechanism is needed to allow the identity to be assured even if th= e > information or signature from the in band mechanism is lost (such as when > the call goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at > the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > 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 From yiu_lee@cable.comcast.com Wed Jun 19 07:37: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 9228521F9CAF for ; Wed, 19 Jun 2013 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 0lEId4HRUjGL for ; Wed, 19 Jun 2013 07:37:32 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1821F9C97 for ; Wed, 19 Jun 2013 07:37:29 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78127081; Wed, 19 Jun 2013 08:36:51 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 10:37:24 -0400 From: "Lee, Yiu" To: "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObPqD88zMB0Ss20iZGGbgRFBatg== Date: Wed, 19 Jun 2013 14:37:23 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DEDDE@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.248] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3454483043_281015" MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:37:37 -0000 --B_3454483043_281015 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit No disagreement. I am curious what Hadriel tried to illustrate in the example so that I can understand his idea better. On 6/19/13 9:37 AM, "Michael Hammer" wrote: >Is that out of scope? > >Should we focus on E.164 first, email-style names second, and the >interworking of the two third? > >That wouldn't preclude reuse of solution to one for the other, or thinking >about that in advance. >But, we are talking about two different authority delegation trees here >and >I am not sure if you want one constrained by solutions for the other. > >If we do, then at least make it clear that is a decision being made. > >Mike > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Lee, >Yiu >Sent: Wednesday, June 19, 2013 9:15 AM >To: stir@ietf.org >Subject: Re: [stir] current draft charter - ENUM and databases > >I am on board using dns for lookup. One question in your example: When you >receive alice@foo.com, how do you derive it to "_cid.foo.com"? Do you >suggest _cid is the tn or some other identifier? > > >On 6/18/13 1:36 PM, "Hadriel Kaplan" wrote: > >>I think that's still possible even for email-style names. For example, >>when receiving a request from'alice@foo.com' we could do a DNS lookup >>for '_cid.foo.com' or some such pre-defined naming scheme, to get the >>caller-id cert for 'foo.com'; or the RR for that DNS key could redirect >>us to somewhere else if need be. Or we could do an HTTP automatically >>for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where >>the last part is a hash of the username. --B_3454483043_281015 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFN/O 4vUDLrjLuafcdVDnCiUfzaI2MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYxOTE0MzcyMVowDQYJKoZIhvcNAQEBBQAEggEAqeHSfIsEWIvOTkDPis5v 8pHP4FxjSIq3bptpNC8pT1FTpYUZifjd2weedvggCWqHCykuTVhRF+UwwXtKpxra2SK6/8DU emKjFUscan+xZFRlk2V8RCyQMoCAlPjZ3i4XNJmDiuCz04aSA4cTTB5sbVkw1y5pkHLsELDp GsmiCROSQIfICfFxure8tIxMMS90ae0ErIYUFvj9CNAgolYo8EfIZrDLZ9IhhlPMSObby+mn PV/+H7VerLQmw6RV20LWHPmmUxd6NSSziG5mYoNtW87jJ8hJ6KBQ5WbYLKOkPaiNHbDXykc3 Jau1S2QzYM3pCEZAetvzhGUExJJWQTKTxQ== --B_3454483043_281015-- From brian.rosen@neustar.biz Wed Jun 19 07:47: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 934B421F9C45 for ; Wed, 19 Jun 2013 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 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 wRWSqd5zraKx for ; Wed, 19 Jun 2013 07:47:53 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7631021F9BC4 for ; Wed, 19 Jun 2013 07:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371653445; x=1687010423; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=c9o8gwC7zt /oBktWRWHNyVaLwekH2SniG8TLEj/HA+s=; b=LvFS/nJjGdFNxXJq62Mqk1cvIF s8QV0wEOswEjSF1hTGCvGU8Cl2CnmfJEYAwS+Kga3v54JsBVVWiv5w3DW/WQ== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25363441; Wed, 19 Jun 2013 10:50:43 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:47:42 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9WfWAgAAHFoA= Date: Wed, 19 Jun 2013 14:47:42 +0000 Message-ID: <9301A30B-C390-4B99-8F5A-B9F17819575A@neustar.biz> References: <51C1BE9B.4090807@dcrocker.net> In-Reply-To: <51C1BE9B.4090807@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tAaioYsPgS7XzCw1pR1pUw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:47:57 -0000 Inline On Jun 19, 2013, at 10:22 AM, Dave Crocker wrote: > On 6/19/2013 6:52 AM, Rosen, Brian wrote: >> 5. We think we need two MECHANISMS, an in-band mechanism that has the >> originating device or service provider signing information and >> carries the signature in the signaling. The other is some out of >> band mechanism that involves some new database or service that gets >> written by the originating device or service provider and checked by >> some downstream entity. The latter mechanism is needed to allow the >> identity to be assured even if the information or signature from the >> in band mechanism is lost (such as when the call goes through an SS7 >> hop). >=20 >=20 > Good list. >=20 > I'd like us to explore #5 carefully. Although it carries the usual appea= l of flexibility. However beyon that intuitive appeal, it dramatically incr= eases complexity and its viable usage is not at all obvious. The motivatin= g rationale in the last sentence sounds great, but that doesn't mean it's v= iable. >=20 > Some examples of questions that such an approach needs to answer: >=20 > 1. What does it do to overall design and operations complexity and cost? Two mechanisms, got to be at least twice the cost >=20 > 2. What is a realistic estimate of the likelihood of major benefit; in ot= her words, why should we believe it will help enough to warrant the added c= osts? Because we want to solve the problem now, where essentially all calls go th= rough an SS7 link. >=20 > 3. What are the added adoption barriers? That depends on the solution. There are several of them, for sure. >=20 > 4. What are the early-stage costs, such as when almost no one has it impl= emented? >=20 > For example, the stated use is when the call request arrives without th= e signature information; this will look exactly the same as a call from a s= ystem that did not add the signature. Initially the latter will be far, fa= r more common than the former. Almost no one will be signing. Hence, the = querying agent is going to be making unsuccessful alternative checks essent= ially every time. Failure rates at that level discourage adoption. For one thing the same is true for the in band mechanism. Sure, there is a cost for the out of band mechanism. It's mostly fixed cost, but there are always transaction volume related cos= ts. =20 Actually, some of us are worried that the problem of the out of band mechan= ism is that by the time we've deployed it, and sunk most of the cost, the p= roblem goes away. Others think that there will always be some barriers and= the out of band mechanism has value for a very long time. The costs are mostly the database itself, and the implementation in whereve= r it is done. In EKR's idea, it's at the ends (device or services). In th= e alternate idea I just described, it's in the gateways (or near them, a B2= BUA could do it). >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From michael.hammer@yaanatech.com Wed Jun 19 07:55: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 1AD0C21F9BF0 for ; Wed, 19 Jun 2013 07:55:04 -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=0.131, 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 oS0ZEqwfCzTq for ; Wed, 19 Jun 2013 07:54:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id C029A21F9BC9 for ; Wed, 19 Jun 2013 07:54:46 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 19 Jun 2013 07:54:46 -0700 From: Michael Hammer To: "Brian.Rosen@neustar.biz" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlCAAEiZgP//wdDQ Date: Wed, 19 Jun 2013 14:54:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3A03DEEBC@ex2k10mb2.corp.yaanatech.com> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> In-Reply-To: <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.216] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0079_01CE6CDB.680A34A0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "pp3129@att.com" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 14:55:17 -0000 ------=_NextPart_000_0079_01CE6CDB.680A34A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK, so this out-of-band was simply focusing on bypassing the SS7 restrictions by allowing the ingress to SS7 and the egress from SS7 to cooperate in passing data that would not fit into SS7. That is a limited and perhaps reasonable work-around. Until now, I had no real idea what you were going for in the out-of-band comments. Mike -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Wednesday, June 19, 2013 10:35 AM To: Michael Hammer Cc: pp3129@att.com; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? Of course, like most of us, you are an engineer, so you want to see that there is at least one solution that could work before you even want to see something in a charter. So, EKR proposed one solution where the source writes a data record in a database encrypted for the termination. All that depends on is the source and destination identities. Ignoring whether you think we can deploy it, it does solve the problem. I'll give you the guts of another solution: The SIP-> SS7 GW writes a record with Called and Calling party TNs, and the SIP headers. The SS7-SIP GW searches for a record with the same called and calling TNs, within a short time frame, and retrieves the SIP headers, which it uses to populate its outgoing message, effectively restoring the signature and the elements that were used when creating it. Ignoring whether you think we could deploy it, it also solves the problem, but only in a more restricted set of situations. There are all sorts of trust issues, cert distribution issues, privacy issues, business model issues, and a host of other stuff, but either of these solutions would work. In this thread, I'd like to stay away from discussing those issues - I'm only trying to convince you that there are reasonable engineering solutions that would work. Once we have a WG, we can work out the issues. In the end, that might fail, but we're starting from reasonable engineering base I think. Brian On Jun 19, 2013, at 10:18 AM, Michael Hammer wrote: > The question of whether this works with SS7 in the path is a key one. > That was part of the reason I was concerned about doing both E.164 and > email identities at the same time. > > I am not buying the out-of-band, not connected to the current state of > the received signaling message, yet. > If the signaling message arrives with different elements, how do I > know that it is the same thing that is being signed out of band? > Versus an imposter? > > Mike > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of PFAUTZ, PENN L > Sent: Wednesday, June 19, 2013 10:06 AM > To: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? > > Brian: > I think this is a helpful summary to keep us on track; thanks for > posting it. I do wonder if the fifth point, about handling SS7 in the > middle may be too ambitious. My own belief is that the best we can > hope to achieve is a solution in the post PSTN transition where we are > end-to-end IP. While there is SS7 in the middle, there will still > likely be SS7 at the beginning or at the end of some calls and I don't > see us fixing those cases. So, I'll be happy if we just get the promised land right. > > 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 Rosen, Brian > Sent: Wednesday, June 19, 2013 9:52 AM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? > > A lot of our discussion is focussed on where certs are found. I want > to make sure that we agree on the basics, because where certs are > found is pretty far down the list of things to agree on. > > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. > The APPROACH we're going to use is to verify the IDENTITY of the > SOURCE of the call, because we believe that spoofing identity or non > providing identity is the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call > and sign or encrypt it in a way that a downstream entity can verify > that the information is valid 4. The CREDENTIALS we're going to use, > for identities that are telephone numbers, is based on delegation of > the number, rooted in the national numbering authority. For > identities that are domain based, the credentials are based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the > originating device or service provider signing information and carries > the signature in the signaling. The other is some out of band > mechanism that involves some new database or service that gets written > by the originating device or service provider and checked by some > downstream entity. The latter mechanism is needed to allow the > identity to be assured even if the information or signature from the > in band mechanism is lost (such as when the call goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) > > > That doesn't say things like where the certs are or what is signed, or > what the out of band mechanism does. > > So, I ask, do you agree with that? > > 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 ------=_NextPart_000_0079_01CE6CDB.680A34A0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYx OTE0NTQ0M1owIwYJKoZIhvcNAQkEMRYEFOz4QXGzZmYVUnIo/k5sIi7Zsi9SMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAClKNjh5EoVjslavHCGO4RMaKKj0QJo0pg3/R3Zcr xxFEQ4tNz0Vpc06Xm3CCNiFgW7vl8r4DNNI4+hbri0MPFUS1/WNRSdP8br7EIuQddBF8hAtflc+7 qy5VfyBbfdxhmSkqMDd1LalppQSsUlNUJy8n/ysnbavLpt6zXiPmhSyto16p8j0S/Zgdm44zPCjY ZCatVYArT6S7hX+P+C07OO6LBf1dmVI5mLnSlLHGZkWZvqZ4IQX0QjmWxe0SZZL/0/asmERd80VO NgNk6RYT9OmzO5r02CFbOQEpmZBo0anANY5jWnEtMsftpdg36moFTXuE+XzhuPCimgihhvJ7OgAA AAAAAA== ------=_NextPart_000_0079_01CE6CDB.680A34A0-- From brian.rosen@neustar.biz Wed Jun 19 08:03: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 5C18221F9CBA for ; Wed, 19 Jun 2013 08:03:50 -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 2s5A1QYiQukD for ; Wed, 19 Jun 2013 08:03:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1214A21F9CB5 for ; Wed, 19 Jun 2013 08:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371654115; x=1687013663; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=iAuaH8eU5G i+2HRR3qS6kNAUqyxJWN8i5aMXFyPbGOI=; b=X5ANV6P5ckiZhL4LbKjbScUIV8 WvM3D+tCG70kb/sDidPL81vy3WnOGaVH00bY9/R2mulvnGk9XkDOf3RA8w3w== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19723702; Wed, 19 Jun 2013 11:01:54 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 11:03:31 -0400 From: "Rosen, Brian" To: Michael Hammer Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlCAAEiZgP//wdDQgABGKYA= Date: Wed, 19 Jun 2013 15:03:31 +0000 Message-ID: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <00C069FD01E0324C9FFCADF539701DB3A03DEEBC@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DEEBC@ex2k10mb2.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: DZF6pJSbrrQN7FKWiuGLFg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "pp3129@att.com" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 15:03:50 -0000 EKRs idea is allow simple in some ways - the origination encrypt details ab= out the call with the credentials of the termination. The termination sear= ches for calls to it. The database validates the credentials of the origin= ation to permit the write. It has some clever ideas on avoiding analysis o= f calling patterns. Brian On Jun 19, 2013, at 10:54 AM, Michael Hammer = wrote: > OK, so this out-of-band was simply focusing on bypassing the SS7 > restrictions by allowing the ingress to SS7 and the egress from SS7 to > cooperate in passing data that would not fit into SS7. > That is a limited and perhaps reasonable work-around. =20 >=20 > Until now, I had no real idea what you were going for in the out-of-band > comments. >=20 > Mike >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Wednesday, June 19, 2013 10:35 AM > To: Michael Hammer > Cc: pp3129@att.com; stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? >=20 > Of course, like most of us, you are an engineer, so you want to see that > there is at least one solution that could work before you even want to se= e > something in a charter. So, EKR proposed one solution where the source > writes a data record in a database encrypted for the termination. All th= at > depends on is the source and destination identities. Ignoring whether yo= u > think we can deploy it, it does solve the problem. >=20 > I'll give you the guts of another solution: The SIP-> SS7 GW writes a > record with Called and Calling party TNs, and the SIP headers. The SS7-S= IP > GW searches for a record with the same called and calling TNs, within a > short time frame, and retrieves the SIP headers, which it uses to populat= e > its outgoing message, effectively restoring the signature and the element= s > that were used when creating it. Ignoring whether you think we could dep= loy > it, it also solves the problem, but only in a more restricted set of > situations. >=20 > There are all sorts of trust issues, cert distribution issues, privacy > issues, business model issues, and a host of other stuff, but either of > these solutions would work. In this thread, I'd like to stay away from > discussing those issues - I'm only trying to convince you that there are > reasonable engineering solutions that would work. Once we have a WG, we = can > work out the issues. In the end, that might fail, but we're starting fro= m > reasonable engineering base I think. >=20 > Brian > On Jun 19, 2013, at 10:18 AM, Michael Hammer > wrote: >=20 >> The question of whether this works with SS7 in the path is a key one. >> That was part of the reason I was concerned about doing both E.164 and=20 >> email identities at the same time. >>=20 >> I am not buying the out-of-band, not connected to the current state of=20 >> the received signaling message, yet. >> If the signaling message arrives with different elements, how do I=20 >> know that it is the same thing that is being signed out of band? >> Versus an imposter? >>=20 >> Mike >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of PFAUTZ, PENN L >> Sent: Wednesday, June 19, 2013 10:06 AM >> To: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] Do we agree on the basics? >>=20 >> Brian: >> I think this is a helpful summary to keep us on track; thanks for=20 >> posting it. I do wonder if the fifth point, about handling SS7 in the=20 >> middle may be too ambitious. My own belief is that the best we can=20 >> hope to achieve is a solution in the post PSTN transition where we are=20 >> end-to-end IP. While there is SS7 in the middle, there will still=20 >> likely be SS7 at the beginning or at the end of some calls and I don't=20 >> see us fixing those cases. So, I'll be happy if we just get the promised > land right. >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Rosen, Brian >> Sent: Wednesday, June 19, 2013 9:52 AM >> To: stir@ietf.org >> Subject: [stir] Do we agree on the basics? >>=20 >> A lot of our discussion is focussed on where certs are found. I want=20 >> to make sure that we agree on the basics, because where certs are=20 >> found is pretty far down the list of things to agree on. >>=20 >> So, do we agree: >> 1. The PROBLEM we're solving is robocalling, vishing and swatting 2.=20 >> The APPROACH we're going to use is to verify the IDENTITY of the=20 >> SOURCE of the call, because we believe that spoofing identity or non=20 >> providing identity is the way the bad calls are being placed. >> 3. The METHOD we're going to use is to pick some data from the call=20 >> and sign or encrypt it in a way that a downstream entity can verify=20 >> that the information is valid 4. The CREDENTIALS we're going to use,=20 >> for identities that are telephone numbers, is based on delegation of=20 >> the number, rooted in the national numbering authority. For=20 >> identities that are domain based, the credentials are based on the domai= n > entry in the DNS. >> 5. We think we need two MECHANISMS, an in-band mechanism that has the=20 >> originating device or service provider signing information and carries=20 >> the signature in the signaling. The other is some out of band=20 >> mechanism that involves some new database or service that gets written=20 >> by the originating device or service provider and checked by some=20 >> downstream entity. The latter mechanism is needed to allow the=20 >> identity to be assured even if the information or signature from the=20 >> in band mechanism is lost (such as when the call goes through an SS7 hop= ). >> 6. The credentials (4) are the same in both mechanisms (5) >>=20 >>=20 >> That doesn't say things like where the certs are or what is signed, or=20 >> what the out of band mechanism does. >>=20 >> So, I ask, do you agree with that? >>=20 >> 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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From timothy.dwight@verizon.com Wed Jun 19 08:08: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 D24B221F9C45 for ; Wed, 19 Jun 2013 08:08:55 -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=[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 KUjhjaHgveSY for ; Wed, 19 Jun 2013 08:08:50 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0830F21F9976 for ; Wed, 19 Jun 2013 08:08:49 -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; 19 Jun 2013 15:08:35 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,898,1363132800"; d="scan'208";a="500342149" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 19 Jun 2013 15:08:13 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 19 Jun 2013 11:08:13 -0400 To: "Rosen, Brian" , "stir@ietf.org" Date: Wed, 19 Jun 2013 11:08:12 -0400 Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9EAqg Message-ID: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> References: 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 Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 15:08:55 -0000 Brian, Thanks for a timely summary. I have some questions I've been hoping would = become clear by monitoring the discussion, that so far haven't. Questions re. scope: -------------------- #1: Is the scope limited to _only_ identities that are or imbed, E.164 num= bers? #2: Does the scope include identities that are or imbed, numbers structure= d per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers= )? #3: Does the scope include identities that are or imbed, national numbers? General Question: ----------------- #4: Is there any actual data behind this initiative? I don't recall seein= g any numbers (e.g., how often do various types of bad things, happen; what= damage is done; is it on the rise or decline). I don't recall any assessm= ent of how these things are being done (just assumptions that they're facil= itated by spoofing caller ID in a VoIP call origination). Yes, I know ther= e are web sites you can go to that let you do exactly that. But do we know= that that's how this mischief is being done? What if it's being initiated= on a circuit switched PBX connected into the POTS network via a PRI, and t= he culprits are leveraging gaps in the interworking of ISUP and SIP to go u= ndetected? If it's knowable we ought to try and know, so that we fix the r= ight problem. I don't recall any analysis of the [in]adequacy of currently= defined mechanisms. Why for example does transitive trust seem to work in= the PSTN but not in SIP? I'm not really trying to invite pontification. I'm asking has any actual i= nvestigation been done, and if so where are the results? A list of URLs wo= uld be great. No offense intended with respect to the interesting technica= l discussions already taking place, but in order to motivate deployment _so= mebody_ is going to have to do this. Regarding the discussion below: ------------------------------- On point #2, can you clarify what is meant by "verify the identity of the s= ource"? What I'm imagining is something like (a) verifying that the callin= g identity is "valid"; and (b) verifying that the calling UA has the "right= " to claim that identity for the purpose of initiating the call in question= . Is that roughly it? If so, can you step through how that validity check= would work? It's kind of a big leap to see how "pick[ing] some data from = the call and sign[ing] it", achieves those objectives. =20 Similarly, what is the rule for when it's OK that entity 'A' assert identit= y (e.g., phone number) 'b'? Some seem obvious, but not all. For example: Case 1: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. =20 Case 2: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. =20 Person 'C' grants to person 'A' permission to identify itself as= 'b'. Case 3: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. =20 Person 'C' grants to person 'A' permission to identify itself as= 'b'; with some constraints (e.g., only at night, or only=20 for 1 day, or only to invoke certain services or call certain nu= mbers). In case 1 it is OK for 'A' to identify itself as 'b'. =20 In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on wh= ether there are restrictions on "sub-assignment" of numbers and if so, whet= her 'C' meets them. =20 In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both = on whether 'C' had authority to 'sub-assign' identity 'b', and whether the = other restrictions specified by 'C' were met. Who would check? Cheers, tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, June 19, 2013 8:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to ma= ke sure that we agree on the basics, because where certs are found is prett= y far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The AP= PROACH we're going to use is to verify the IDENTITY of the SOURCE of the ca= ll, because we believe that spoofing identity or non providing identity is = the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sig= n or encrypt it in a way that a downstream entity can verify that the infor= mation is valid 4. The CREDENTIALS we're going to use, for identities that = are telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the cr= edentials are based on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the origi= nating device or service provider signing information and carries the signa= ture in the signaling. The other is some out of band mechanism that involv= es some new database or service that gets written by the originating device= or service provider and checked by some downstream entity. The latter mec= hanism is needed to allow the identity to be assured even if the informatio= n or signature from the in band mechanism is lost (such as when the call go= es through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what= the out of band mechanism does. So, I ask, do you agree with that? Brian _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From pp3129@att.com Wed Jun 19 08:15: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 2035A21F9C86 for ; Wed, 19 Jun 2013 08:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Ff6n7Mki7qXn for ; Wed, 19 Jun 2013 08:15:11 -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 E0CA121F9C2F for ; Wed, 19 Jun 2013 08:15:10 -0700 (PDT) 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 efac1c15.0.530288.00-387.1454321.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 19 Jun 2013 15:15:10 +0000 (UTC) X-MXL-Hash: 51c1cafe2bcfa801-56f677e4b78808b26a40dd05ec5c8f65586cd6c6 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 r5JFFAEj001399; Wed, 19 Jun 2013 11:15:10 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5JFExEP001078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 11:15:04 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 19 Jun 2013 15:14:44 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 11:14:51 -0400 From: "PFAUTZ, PENN L" To: "Dwight, Timothy M (Tim)" , "Rosen, Brian" , "stir@ietf.org" Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9EAqggAAUpcA= Date: Wed, 19 Jun 2013 15:14:50 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60495F32D@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.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.20.146] X-AnalysisOut: [v=2.0 cv=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=vt7402L8E50A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ocOsavY7rbkA:10 a=48vgC7mUAAAA:8 a=AeShQu-C1NnpVc] X-AnalysisOut: [ooY28A:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=jKscjIv7FeTLsPpC:21 a=CHpniq7j0CShi1WJ:21] Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 15:15:17 -0000 +1 to the concern about non-VoIP based spoofing and the issue of legitimate= use of a number assigned to another party. To be specific, lots of compani= es contract with call centers for telemarketing. They want the calling part= y number to show the toll free number of the company with the product, not = the telemarketer. 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 Dwi= ght, Timothy M (Tim) Sent: Wednesday, June 19, 2013 11:08 AM To: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? Brian, Thanks for a timely summary. I have some questions I've been hoping would = become clear by monitoring the discussion, that so far haven't. Questions re. scope: -------------------- #1: Is the scope limited to _only_ identities that are or imbed, E.164 num= bers? #2: Does the scope include identities that are or imbed, numbers structure= d per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers= )? #3: Does the scope include identities that are or imbed, national numbers? General Question: ----------------- #4: Is there any actual data behind this initiative? I don't recall seein= g any numbers (e.g., how often do various types of bad things, happen; what= damage is done; is it on the rise or decline). I don't recall any assessm= ent of how these things are being done (just assumptions that they're facil= itated by spoofing caller ID in a VoIP call origination). Yes, I know ther= e are web sites you can go to that let you do exactly that. But do we know= that that's how this mischief is being done? What if it's being initiated= on a circuit switched PBX connected into the POTS network via a PRI, and t= he culprits are leveraging gaps in the interworking of ISUP and SIP to go u= ndetected? If it's knowable we ought to try and know, so that we fix the r= ight problem. I don't recall any analysis of the [in]adequacy of currently= defined mechanisms. Why for example does transitive trust seem to work in= the PSTN but not in SIP? I'm not really trying to invite pontification. I'm asking has any actual i= nvestigation been done, and if so where are the results? A list of URLs wo= uld be great. No offense intended with respect to the interesting technica= l discussions already taking place, but in order to motivate deployment _so= mebody_ is going to have to do this. Regarding the discussion below: ------------------------------- On point #2, can you clarify what is meant by "verify the identity of the s= ource"? What I'm imagining is something like (a) verifying that the callin= g identity is "valid"; and (b) verifying that the calling UA has the "right= " to claim that identity for the purpose of initiating the call in question= . Is that roughly it? If so, can you step through how that validity check= would work? It's kind of a big leap to see how "pick[ing] some data from = the call and sign[ing] it", achieves those objectives. Similarly, what is the rule for when it's OK that entity 'A' assert identit= y (e.g., phone number) 'b'? Some seem obvious, but not all. For example: Case 1: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. Case 2: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as= 'b'. Case 3: numbering plan administrator has assigned identity 'b' to carrie= r 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as= 'b'; with some constraints (e.g., only at night, or only for 1 day, or only to invoke certain services or call certain nu= mbers). In case 1 it is OK for 'A' to identify itself as 'b'. In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on wh= ether there are restrictions on "sub-assignment" of numbers and if so, whet= her 'C' meets them. In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both = on whether 'C' had authority to 'sub-assign' identity 'b', and whether the = other restrictions specified by 'C' were met. Who would check? Cheers, tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, June 19, 2013 8:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to ma= ke sure that we agree on the basics, because where certs are found is prett= y far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The AP= PROACH we're going to use is to verify the IDENTITY of the SOURCE of the ca= ll, because we believe that spoofing identity or non providing identity is = the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sig= n or encrypt it in a way that a downstream entity can verify that the infor= mation is valid 4. The CREDENTIALS we're going to use, for identities that = are telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the cr= edentials are based on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the origi= nating device or service provider signing information and carries the signa= ture in the signaling. The other is some out of band mechanism that involv= es some new database or service that gets written by the originating device= or service provider and checked by some downstream entity. The latter mec= hanism is needed to allow the identity to be assured even if the informatio= n or signature from the in band mechanism is lost (such as when the call go= es through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what= the out of band mechanism does. So, I ask, do you agree with that? 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 philippe.fouquart@orange.com Wed Jun 19 09:12: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 E761A21F9D56 for ; Wed, 19 Jun 2013 09:12:18 -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 pCP++JeJvnHT for ; Wed, 19 Jun 2013 09:12:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68521F9D94 for ; Wed, 19 Jun 2013 09:12:07 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1204122D98D; Wed, 19 Jun 2013 18:12:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EBAB74C07A; Wed, 19 Jun 2013 18:12:05 +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, 19 Jun 2013 18:12:05 +0200 From: To: "Rosen, Brian" , "stir@ietf.org" Thread-Topic: Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9Fy3A Date: Wed, 19 Jun 2013 16:12:04 +0000 Message-ID: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] 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.19.141224 Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 16:12:19 -0000 This looks good to me, thanks for summing this up. For the record, I share = the observations/reservations that have already been made on point 5 for th= e out-of-band mechanism and the practicalities of a gradual deployment.=20= =20 The other thing that slightly puzzles me (and that I don't quite see in oth= er comments) is the statement about "identities that are domain based" ("th= e credentials are based on the domain entry in the DNS "). Given that the p= roposed charter doesn't talk about what is meant to be in scope in terms of= URI format and what isn't, maybe this exercise will be necessary at some p= oint to move forward (or if this ""domain-based identity" is meant to clari= fy this, my apologies, I don't quite get it.)=20 This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;= user=3Dphone to be validated by the endpoint, the host part must remain unt= ouched end-to-end since, if I read the above correctly, the credentials for= +CC-XXXXXX will have to be found under domain.com (and I don't mean this l= iterally in the DNS). Is this correct? (incidentally to me this clearly res= tricts the use case to calling party numbers, your point 2., since for call= ed parties as others have pointed out, in some networks, the host part is g= enerally for good or bad irrelevant when the SIP URI conveys an encapsulate= d tel)=20 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 Ros= en, Brian Sent: Wednesday, June 19, 2013 3:52 PM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to ma= ke sure that we agree on the basics, because where certs are found is prett= y far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE = of the call, because we believe that spoofing identity or non providing ide= ntity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sig= n or encrypt it in a way that a downstream entity can verify that the infor= mation is valid 4. The CREDENTIALS we're going to use, for identities that are telephone nu= mbers, is based on delegation of the number, rooted in the national numberi= ng authority. For identities that are domain based, the credentials are ba= sed on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the origi= nating device or service provider signing information and carries the signa= ture in the signaling. The other is some out of band mechanism that involv= es some new database or service that gets written by the originating device= or service provider and checked by some downstream entity. The latter mec= hanism is needed to allow the identity to be assured even if the informatio= n or signature from the in band mechanism is lost (such as when the call go= es through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what= the out of band mechanism does. So, I ask, do you agree with that? Brian _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From dhc@dcrocker.net Wed Jun 19 09:21: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 A87B821F9C61 for ; Wed, 19 Jun 2013 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 pPfdJt5-T9mB for ; Wed, 19 Jun 2013 09:21:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 252ED21F9C6B for ; Wed, 19 Jun 2013 09:21:46 -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 r5JGLgPX020356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 09:21:46 -0700 Message-ID: <51C1DA86.8040901@dcrocker.net> Date: Wed, 19 Jun 2013 09:21:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" 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]); Wed, 19 Jun 2013 09:21:46 -0700 (PDT) Cc: "stir@ietf.org" Subject: [stir] Out of band (was: Re: Do we agree on the basics?) 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, 19 Jun 2013 16:21:53 -0000 On 6/19/2013 6:52 AM, Rosen, Brian wrote: > 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). Perhaps I'm misunderstanding its expected usage scenario, but problems with gatewaying to/from SS7 are being cited as the rationale for the out of band mechanism. As such, it sounds like an issue that does not involve the core design, but rather a kind of workaround for a hop that doesn't support that core design. If so, it should be specified as a separate mechanism to be applied in only specific cases. In some environments, the hack for overcoming such a limitation is tunneling. That is, encapsulated things to hide them from the hop that lacks support. I don't think there's common term for using a side-stash of the information, but we should invent one. As I understand the requirement, it might make sense to specify it as an additional mechanism to be used only by SIP/SS7 and SS7/SIP gateways. When transiting SIP/SS7, the information is stored into the side cache. When transiting SS7/SIP, the cache is queried; if an entry is found, the STIR information is restored in native form. There is still the small matter of vanishingly small success for the SS7/SIP queries that will happen for a very long time. This really creates a very strong disincentive for the sizable additional cost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Jun 19 10:12: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 68C9321F9AAD for ; Wed, 19 Jun 2013 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 sz+v4DiS3N+1 for ; Wed, 19 Jun 2013 10:12:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF121F8EAE for ; Wed, 19 Jun 2013 10:12:15 -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 r5JH5uuk015998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 17:05:56 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 r5JHCCEf014561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 17:12:13 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 r5JHCBI7011939; Wed, 19 Jun 2013 17:12:12 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 10:12:11 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 19 Jun 2013 13:12:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A78B3BE-F3C5-4B40-BBAB-EAFFBED57D3E@oracle.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:12:23 -0000 [background:] For the "email-style" case what I mean is a source = identity of something like 'alice@foo.com', where by definition = 'foo.com' is authoritative for usernames within its domain, and the = scope of the 'alice' is constrained to the 'foo.com' domain. What I = *don't* mean is an E.164 that just happens to be encoded in a SIP URI = like 'sip:+12125551212@foo.com'. There is no TN for a "email-style" = URI, for the term "email-style" I'm using anyway. So for en email-style URI, the premise I'm assuming is the same as RFC = 4474: a certificate identifying 'foo.com' signed by a trusted CA is = sufficient to believe it's really a valid =46rom of 'alice@foo.com'. So = all the verifier needs is the certificate of the From's domain, to = verify the signer/originator can claim the user name. In RFC 4474 that = certificate is retrieved via an HTTP URL that the originator provides in = a SIP header. I'm just saying it's not absolutely necessary that a URL = be provided in a SIP header, but we could instead get it from DNS. We have can't just look up the DNS domain key of 'foo.com' to get the = certificate, though, because 'foo.com' will resolve to stuff used for = other things that we don't care about. So a relatively common tactic = people use is to prefix the DNS query key with a = pre-defined/standardized/agreed-upon string for a specific node of the = domain (creating an artificial name basically). The '_cid' is just an = example of such a prefix string we could standardize using. So everyone = would know to add a '_cid.' to the domain name of the email-stlye domain = in the received =46rom to find the cert in DNS for that domain; and that = domain would know to put it there for everyone to get. -hadriel On Jun 19, 2013, at 9:14 AM, "Lee, Yiu" = wrote: > I am on board using dns for lookup. One question in your example: When = you > receive alice@foo.com, how do you derive it to "_cid.foo.com"? Do you > suggest _cid is the tn or some other identifier? >=20 >=20 > On 6/18/13 1:36 PM, "Hadriel Kaplan" = wrote: >=20 >> I think that's still possible even for email-style names. For = example, >> when receiving a request from'alice@foo.com' we could do a DNS lookup = for >> '_cid.foo.com' or some such pre-defined naming scheme, to get the >> caller-id cert for 'foo.com'; or the RR for that DNS key could = redirect >> us to somewhere else if need be. Or we could do an HTTP = automatically >> for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' = where >> the last part is a hash of the username. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Wed Jun 19 10: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 104EF21F9E17 for ; Wed, 19 Jun 2013 10:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 oJPSdHSx83dj for ; Wed, 19 Jun 2013 10:21:56 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD721F9B2D for ; Wed, 19 Jun 2013 10:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371662692; x=1687019469; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=J7BVK1z3qN n4WiPVAf4RCs5SnoWARuK5uOg4zi9EKAg=; b=kmaPRJM+EFPVTed47KfhMJ7qdt CcJ84C389iZ2rmtqrzbv2+yOIeb+0M8eHXZ03AgnhrNhdyCe9YOKAdEqJL5w== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25371978; Wed, 19 Jun 2013 13:24:51 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:21:45 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out of band (was: Re: Do we agree on the basics?) Thread-Index: AQHObRF4IV1AWOll3U2zScXllcPDAQ== Date: Wed, 19 Jun 2013 17:21:44 +0000 Message-ID: <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> In-Reply-To: <51C1DA86.8040901@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Afnv+vzG7W5W/YVUWa7r7g== Content-Type: text/plain; charset="us-ascii" Content-ID: <9D5A5CD0E9AD2E4BAC36259BD09F5D63@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out of band (was: Re: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:22:00 -0000 To be fair, there are some scenarios other than SS7 links where the informa= tion is lost. If we go for an SS7-only solution, we don't cover those case= s. The mechanisms may be able to be used in other environments. I don't know why you think that we have "vanishingly small success for the = SS7/SIP queries". Brian On Jun 19, 2013, at 12:21 PM, Dave Crocker wrote: > On 6/19/2013 6:52 AM, Rosen, Brian wrote: >> 5. We think we need two MECHANISMS, an in-band mechanism that has the or= iginating device or service provider signing information and carries the si= gnature in the signaling. The other is some out of band mechanism that inv= olves some new database or service that gets written by the originating dev= ice or service provider and checked by some downstream entity. The latter = mechanism is needed to allow the identity to be assured even if the informa= tion or signature from the in band mechanism is lost (such as when the call= goes through an SS7 hop). >=20 >=20 > Perhaps I'm misunderstanding its expected usage scenario, but problems wi= th gatewaying to/from SS7 are being cited as the rationale for the out of b= and mechanism. As such, it sounds like an issue that does not involve the = core design, but rather a kind of workaround for a hop that doesn't support= that core design. If so, it should be specified as a separate mechanism t= o be applied in only specific cases. >=20 > In some environments, the hack for overcoming such a limitation is tunnel= ing. That is, encapsulated things to hide them from the hop that lacks sup= port. I don't think there's common term for using a side-stash of the info= rmation, but we should invent one. As I understand the requirement, it mig= ht make sense to specify it as an additional mechanism to be used only by S= IP/SS7 and SS7/SIP gateways. >=20 > When transiting SIP/SS7, the information is stored into the side cache. = When transiting SS7/SIP, the cache is queried; if an entry is found, the ST= IR information is restored in native form. >=20 > There is still the small matter of vanishingly small success for the SS7/= SIP queries that will happen for a very long time. This really creates a v= ery strong disincentive for the sizable additional cost. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Wed Jun 19 10:23: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 9584A21F9E52 for ; Wed, 19 Jun 2013 10:23:48 -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 Dz-trt63fVCF for ; Wed, 19 Jun 2013 10:23:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4421F9E4F for ; Wed, 19 Jun 2013 10:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371662574; x=1687020983; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=hA1NeNOizP A0Ie9oGVhCIEK8ARS1sF+nkQsBx+Sqync=; b=WX/tglzbxioe4jMK5Od2rSJN2D YTLqXMz2L2w74xjWQ+3yTC3vcj1I0KZhKsKZRkATlHOmEiKzQinb0PEnftiw== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21172304; Wed, 19 Jun 2013 13:22:53 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:23:39 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9Fy3AgAB1cIA= Date: Wed, 19 Jun 2013 17:23:38 +0000 Message-ID: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: nk21UsQUKpyXCkU9/mo/Vg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:23:48 -0000 "domain based identities" =3D identities of the form sip:user@example.com. It DOES NOT include TN@example.com;user=3Dphone Brian On Jun 19, 2013, at 12:12 PM, wrote: > This looks good to me, thanks for summing this up. For the record, I shar= e the observations/reservations that have already been made on point 5 for = the out-of-band mechanism and the practicalities of a gradual deployment. = =20 >=20 > The other thing that slightly puzzles me (and that I don't quite see in o= ther comments) is the statement about "identities that are domain based" ("= the credentials are based on the domain entry in the DNS "). Given that the= proposed charter doesn't talk about what is meant to be in scope in terms = of URI format and what isn't, maybe this exercise will be necessary at some= point to move forward (or if this ""domain-based identity" is meant to cla= rify this, my apologies, I don't quite get it.)=20 >=20 > This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.co= m;user=3Dphone to be validated by the endpoint, the host part must remain u= ntouched end-to-end since, if I read the above correctly, the credentials f= or +CC-XXXXXX will have to be found under domain.com (and I don't mean this= literally in the DNS). Is this correct? (incidentally to me this clearly r= estricts the use case to calling party numbers, your point 2., since for ca= lled parties as others have pointed out, in some networks, the host part is= generally for good or bad irrelevant when the SIP URI conveys an encapsula= ted tel)=20 >=20 > 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= osen, Brian > Sent: Wednesday, June 19, 2013 3:52 PM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to = make sure that we agree on the basics, because where certs are found is pre= tty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting > 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURC= E of the call, because we believe that spoofing identity or non providing i= dentity is the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign or encrypt it in a way that a downstream entity can verify that the inf= ormation is valid > 4. The CREDENTIALS we're going to use, for identities that are telephone = numbers, is based on delegation of the number, rooted in the national numbe= ring authority. For identities that are domain based, the credentials are = based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the ori= ginating device or service provider signing information and carries the sig= nature in the signaling. The other is some out of band mechanism that invo= lves some new database or service that gets written by the originating devi= ce or service provider and checked by some downstream entity. The latter m= echanism is needed to allow the identity to be assured even if the informat= ion or signature from the in band mechanism is lost (such as when the call = goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > Brian > _______________________________________________ > 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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From yiu_lee@cable.comcast.com Wed Jun 19 10:23: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 330D321F9E5F for ; Wed, 19 Jun 2013 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 xfd6IlA6Wtrz for ; Wed, 19 Jun 2013 10:23:48 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD521F9E50 for ; Wed, 19 Jun 2013 10:23:47 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78175171; Wed, 19 Jun 2013 11:23:11 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 13:23:44 -0400 From: "Lee, Yiu" To: "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObRG/xVcGqON8VkmvsVqxM6cF9Q== Date: Wed, 19 Jun 2013 17:23:43 +0000 Message-ID: In-Reply-To: <6A78B3BE-F3C5-4B40-BBAB-EAFFBED57D3E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.246] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3454493023_628551" MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:23:55 -0000 --B_3454493023_628551 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Can we get the dnskey record and verify it by the ds record and forget the whole CA thing? On 6/19/13 1:12 PM, "Hadriel Kaplan" wrote: >We have can't just look up the DNS domain key of 'foo.com' to get the >certificate --B_3454493023_628551 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFM9k 8Pk1y9mK4Tj76QGOWvoGrf8KMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYxOTE3MjM0MlowDQYJKoZIhvcNAQEBBQAEggEAUuLivWD3KxAaekYa9FOP 6osA1PntobHFWgMwsJOnsy4QRn8OzQQVZIlRVesvhWHFwR8684ku3lRXrlB5cXaWm5qHGHIq dCFFsjEKgp7UlNES2UC5nesH9Z20wTgKdM64HwXhuPlpHhcahM/KtVeznrXRMW9OWYWYUw7Z Z42EBqaKEMLtxdFZEzSx6/+6XAHmucAP4FDINYdkgzUnLFZMOW5YSKBrWpapBf8KszP+tMfz PGsnQmbOIvwmXUx+0jhuZ4Z6Ytjj8e5qO1fR6J+glRRyveJJuWm+0JWWJpsTpOKc8+ESKIku IARcwWrDGB3fqVXI9KGA4MJR0/2I3Lu7hg== --B_3454493023_628551-- From dhc@dcrocker.net Wed Jun 19 10:26: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 57AF521F9B63 for ; Wed, 19 Jun 2013 10:26:11 -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 OBgl-w9Qr2tL for ; Wed, 19 Jun 2013 10:26:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 338EE21F9ABB for ; Wed, 19 Jun 2013 10:26:06 -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 r5JHQ2oi021963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 10:26:05 -0700 Message-ID: <51C1E99A.6080507@dcrocker.net> Date: Wed, 19 Jun 2013 10:25:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> In-Reply-To: <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> 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, 19 Jun 2013 10:26:05 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out of band 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, 19 Jun 2013 17:26:11 -0000 On 6/19/2013 10:21 AM, Rosen, Brian wrote: > To be fair, there are some scenarios other than SS7 links where the information is lost. If we go for an SS7-only solution, we don't cover those cases. The mechanisms may be able to be used in other environments. What scenarios, specifically? > I don't know why you think that we have "vanishingly small success for the SS7/SIP queries". This is Transition 101. In the absence of an explicit indicator of support, checking for the data is blind; a query must be done every time, whether it will succeed or not. Because there is not universal cut-over event, adoption is incremental. The world starts with zero adoption and tries to move in a positive direction. Until adoption is very widespread, the likelihood that a query will succeed is small because the proportion of adopters doing signing is small. Vanishingly small. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Jun 19 10:32: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 E4F4821F9E2F for ; Wed, 19 Jun 2013 10:32:29 -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 sXjriBiEEqQO for ; Wed, 19 Jun 2013 10:32:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 66CC821F9E3E for ; Wed, 19 Jun 2013 10:32:23 -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 r5JHQ2k0005791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 17:26:03 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 r5JHWI0e024204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 17:32:19 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 r5JHWI5W001176; Wed, 19 Jun 2013 17:32:18 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 10:32:18 -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: <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> Date: Wed, 19 Jun 2013 13:32:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Michael Hammer , "pp3129@att.com" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:32:30 -0000 On Jun 19, 2013, at 10:34 AM, "Rosen, Brian" = wrote: > Of course, like most of us, you are an engineer, so you want to see = that there is at least one solution that could work before you even want = to see something in a charter. So, EKR proposed one solution where the = source writes a data record in a database encrypted for the termination. = All that depends on is the source and destination identities. Ignoring = whether you think we can deploy it, it does solve the problem. So does putting the info on a piece of paper, rolling it up, attaching = the roll to the leg of a carrier pigeon, and pushing the pigeon out the = window. But I don't think we can ignore that such a solution isn't = deployable. (mostly because there aren't enough qualified pigeons) I'm not trying to be difficult - I'm worried because in the BOFs that = I've been to before, whether a problem is solvable in a = useful/deployable fashion is often a criteria for getting a Working = Group created. Or instead during the BOF we get bogged down with lots = of microphone discussion about the viability of solutions, and run out = of time resulting in a request for another BOF before getting a Working = Group. -hadriel From brian.rosen@neustar.biz Wed Jun 19 10: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 E914221F9CE8 for ; Wed, 19 Jun 2013 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 CAz-S5GriEtk for ; Wed, 19 Jun 2013 10:40:09 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B27D421F9D4D for ; Wed, 19 Jun 2013 10:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371664101; x=1687019763; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=CnV/f8Th9d woBubZIac1foydOfqI35YN+nWJ1+ZieIk=; b=RVMAtJEq/EMW2apJMTF/2dSbqk /G9A12git8XyLW04+QJQfK6t+bNTvIY9R6T7oTCq6dN3mru5A7iIt+8n4KxQ== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26547277; Wed, 19 Jun 2013 13:48:20 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:40:03 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9EAqggACBKQA= Date: Wed, 19 Jun 2013 17:40:03 +0000 Message-ID: <4BED381F-553B-4425-A4B0-A47511A433E4@neustar.biz> References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LJOCCbiJfqPnghf9Uzbm+A== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:40:13 -0000 On Jun 19, 2013, at 11:08 AM, "Dwight, Timothy M (Tim)" wrote: > Brian, >=20 > Thanks for a timely summary. I have some questions I've been hoping woul= d become clear by monitoring the discussion, that so far haven't. >=20 > Questions re. scope: > -------------------- > #1: Is the scope limited to _only_ identities that are or imbed, E.164 n= umbers? Some of us want to be able to expand to user@domain identities, but that is= n't the problem we are solving > #2: Does the scope include identities that are or imbed, numbers structu= red per Rec. E.164 that aren't end point identifiers (e.g., toll free numbe= rs)? Yes > #3: Does the scope include identities that are or imbed, national number= s? Yes, although we can't go beyond what you do today - you can't call them in= ternationally for example. I don't think scope includes service numbers li= ke 511 though. >=20 > General Question: > ----------------- > #4: Is there any actual data behind this initiative? I don't recall see= ing any numbers (e.g., how often do various types of bad things, happen; wh= at damage is done; is it on the rise or decline). I don't recall any asses= sment of how these things are being done (just assumptions that they're fac= ilitated by spoofing caller ID in a VoIP call origination). Yes, I know th= ere are web sites you can go to that let you do exactly that. But do we kn= ow that that's how this mischief is being done? What if it's being initiat= ed on a circuit switched PBX connected into the POTS network via a PRI, and= the culprits are leveraging gaps in the interworking of ISUP and SIP to go= undetected? If it's knowable we ought to try and know, so that we fix the= right problem. I don't recall any analysis of the [in]adequacy of current= ly defined mechanisms. Why for example does transitive trust seem to work = in the PSTN but not in SIP? I don't have numbers. Henning might. I know that some specific offenders = have been traced and found, and they were using VoIP on their side. >=20 > I'm not really trying to invite pontification. I'm asking has any actual= investigation been done, and if so where are the results? A list of URLs = would be great. No offense intended with respect to the interesting techni= cal discussions already taking place, but in order to motivate deployment _= somebody_ is going to have to do this. >=20 >=20 > Regarding the discussion below: > ------------------------------- > On point #2, can you clarify what is meant by "verify the identity of the= source"? What I'm imagining is something like (a) verifying that the call= ing identity is "valid"; and (b) verifying that the calling UA has the "rig= ht" to claim that identity for the purpose of initiating the call in questi= on. Is that roughly it? If so, can you step through how that validity che= ck would work? It's kind of a big leap to see how "pick[ing] some data fro= m the call and sign[ing] it", achieves those objectives. =20 Yes, you have that correct. So you get a credential that comes to you because you were delegated a numb= er or range of numbers. Every time a delegation happens, a new cert is cre= ated. So if an enterprise got a delegation of 10 numbers from a VoIP resel= ler, who got them from a VoIP SP, who got them from a certificated carrier,= who got them from the Pooling Admin, who got them from the NANPA, then the= re were 4 certs in the path. The enterprise signs its outgoing calls with = the cert it got. It's traceable all the way back to NANPA. So you take a set of information from the SIP signaling - we're discussing = the details, but it's something like Called and Calling Party Telephone Num= bers, a Call Id and a time stamp. You compute a signature over that info. = You include the signature, and either the cert itself, or a URI to it, in = the SIP signaling. Any downstream entity can extract the information from the signaling, recom= pute the signature, check it, and verify that the cert is (still) valid for= the range. If any of that information is changed, the signature wouldn't verify. But,= more importantly, the signature can be proved to be that of the cert holde= r, so we know who sent the call. And we know that the cert holder was dele= gated the number (which covered by the signature). If a downstream entity = only accepts calls with valid identity, that means it only accepts calls wi= th a signed identity header, signed by an entity that was delegated the TN = in the identity. Is that clear? >=20 > Similarly, what is the rule for when it's OK that entity 'A' assert ident= ity (e.g., phone number) 'b'? Some seem obvious, but not all. For example= : >=20 > Case 1: numbering plan administrator has assigned identity 'b' to carri= er 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. =20 Administer issues cert to carrier X. Carrier X issues cert to A > Case 2: numbering plan administrator has assigned identity 'b' to carri= er 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. =20 > Person 'C' grants to person 'A' permission to identify itself a= s 'b'. Administer issues cert to carrier X. Carrier X issues cert to C. C issues = cert to A. =20 > Case 3: numbering plan administrator has assigned identity 'b' to carr= ier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. =20 > Person 'C' grants to person 'A' permission to identify itself a= s 'b'; with some constraints (e.g., only at night, or only=20 > for 1 day, or only to invoke certain services or call certain n= umbers). We haven't discussed constraints.. Only for one day is easy. We'd have to= work on other constraints. >=20 > In case 1 it is OK for 'A' to identify itself as 'b'. =20 > In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on = whether there are restrictions on "sub-assignment" of numbers and if so, wh= ether 'C' meets them. =20 > In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending bot= h on whether 'C' had authority to 'sub-assign' identity 'b', and whether th= e other restrictions specified by 'C' were met. Who would check? >=20 >=20 > Cheers, >=20 > tim >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Wednesday, June 19, 2013 8:52 AM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to = make sure that we agree on the basics, because where certs are found is pre= tty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The = APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the = call, because we believe that spoofing identity or non providing identity i= s the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign or encrypt it in a way that a downstream entity can verify that the inf= ormation is valid 4. The CREDENTIALS we're going to use, for identities tha= t are telephone numbers, is based on delegation of the number, rooted in th= e national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the ori= ginating device or service provider signing information and carries the sig= nature in the signaling. The other is some out of band mechanism that invo= lves some new database or service that gets written by the originating devi= ce or service provider and checked by some downstream entity. The latter m= echanism is needed to allow the identity to be assured even if the informat= ion or signature from the in band mechanism is lost (such as when the call = goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > 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 jon.peterson@neustar.biz Wed Jun 19 10:42: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 8EB3C21F9D5D for ; Wed, 19 Jun 2013 10:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 hhPq51tZtRYG for ; Wed, 19 Jun 2013 10:42:51 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 519BA21F9D52 for ; Wed, 19 Jun 2013 10:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371663950; x=1687019469; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=xvvtMxKelG 0PE0wvYQHqNSTSKeRs9wcMKVSJQXvVPB4=; b=N8mAHIvk1dKbNm/S9y7HIHhcSY pOzfdEtVpKFVW65/OVJUi+wLqOpGb911NiSvDoMrwnwdz+Y3knEq8GqmAmYQ== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25373918; Wed, 19 Jun 2013 13:45:49 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:42:45 -0400 From: "Peterson, Jon" To: "Dwight, Timothy M (Tim)" , "Rosen, Brian" , "stir@ietf.org" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9EAqggAAMjoA= Date: Wed, 19 Jun 2013 17:42:45 +0000 Message-ID: In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: GZcZCRIgrQjHWpzuFxIFZA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:42:55 -0000 I'll take a stab at this, below, though I wouldn't describe these as settled issues. On 6/19/13 8:08 AM, "Dwight, Timothy M (Tim)" wrote: >Brian, > >Thanks for a timely summary. I have some questions I've been hoping >would become clear by monitoring the discussion, that so far haven't. > >Questions re. scope: >-------------------- >#1: Is the scope limited to _only_ identities that are or imbed, E.164 >numbers? The problem we're trying to fix is specific to telephone numbers, but as the answers below suggest, not just E.164 numbers. One small caveat: if in fact we build on the existing work in RFC4474, we would be effectively extending a mechanism that does cover non-TN identifiers (sip:user@domain style) to now cover TN identifiers. So for example, RFC4474bis would have provisions for both. But the point of the proposed STIR work is secure telephone numbers. >#2: Does the scope include identities that are or imbed, numbers >structured per Rec. E.164 that aren't end point identifiers (e.g., toll >free numbers)? I think ideally nationally-specific numbers should also be in scope, including freephone numbers. I should be able to get a call from United's IVR that uses a freephone number as a calling party number with a valid identity signature. Understood that the authority for these numbers is managed differently than for ordinary numbers. >#3: Does the scope include identities that are or imbed, national >numbers? As above, at least some. There are corner case and hard edges to consider here. I'd like identity to work for text messaging as well as calls. Does that mean short codes in scope - that is, are there use cases where you can get a text from a short code? Will there be some national authorities who want to be able to claim an emergency number as a calling party number, ever - will reverse 911 show up literally as from "911"? I don't think I have the answers to all of that, and it's not within the scope of the administrative databases of the PSTN today to say who is authoritative to claim "911" as a calling number. > >General Question: >----------------- >#4: Is there any actual data behind this initiative? I don't recall >seeing any numbers (e.g., how often do various types of bad things, >happen; what damage is done; is it on the rise or decline). I don't >recall any assessment of how these things are being done (just >assumptions that they're facilitated by spoofing caller ID in a VoIP call >origination). Yes, I know there are web sites you can go to that let you >do exactly that. But do we know that that's how this mischief is being >done? What if it's being initiated on a circuit switched PBX connected >into the POTS network via a PRI, and the culprits are leveraging gaps in >the interworking of ISUP and SIP to go undetected? If it's knowable we >ought to try and know, so that we fix the right problem. I don't recall >any analysis of the [in]adequacy of currently defined mechanisms. Why >for example does transitive trust seem to work in the PSTN but not in SIP? Henning has some charts about the bad behind swatting, vishing and robocalling. Really I'd say that FCC's efforts to respond to consumer complaints and widespread perceptions of challenges in this area the primary impetus for us to revisit this problem space. Perhaps we should get a link to Henning's preso into the STIR archives. To your last point, if transitive trust worked in the PSTN, we would have none of those problems. As you rightly point out, transitive trust for source identity hasn't been totally reliable in the PSTN since some service providers starting accepting the asserted source numbers of Q.931 SETUP messages and putting them directly into the CIN fields of IAMs. That was around long before VoIP was a material concern. The difference is that the Internet has increased both the number of gateways and the programmability of gateways. There has been some talk on the list in the past couple of days about the "out-of-band" prong of STIR's scope. The original idea behind out-of-band was to attempt to leverage the increasing amount of smarts in devices to improve security even when SIP is only signaled in part of the call path, or even not at all. So yes, there are non-SIP dimensions to this problem space, and yes, trying to address them is in the proposed scope of STIR. We all however acknowledge that this will be a longer-term deliverable, if we take it on. >I'm not really trying to invite pontification. I'm asking has any actual >investigation been done, and if so where are the results? A list of URLs >would be great. No offense intended with respect to the interesting >technical discussions already taking place, but in order to motivate >deployment _somebody_ is going to have to do this. > > >Regarding the discussion below: >------------------------------- >On point #2, can you clarify what is meant by "verify the identity of the >source"? What I'm imagining is something like (a) verifying that the >calling identity is "valid"; and (b) verifying that the calling UA has >the "right" to claim that identity for the purpose of initiating the call >in question. =20 It's closer to (b). Or at least I don't know what "valid" means. Even knowing that the number is assigned, and in that sense valid, would help some, if that's what you mean. But we are trying to get somewhere closer to (b). >Is that roughly it? If so, can you step through how that validity check >would work? It's kind of a big leap to see how "pick[ing] some data from >the call and sign[ing] it", achieves those objectives. We have some input drafts about this, and some older work that we propose to build on. At this stage of the work, though, when we're discussing chartering here in the IETF, we don't necessarily have to agree on details of the solution so much as how we plan to try to attack the problem. I could give you at least a straw man answer to your questions here, but do bear in mind, this doesn't necessarily reflect the consensus of the group and is just an example. Verizon has a credential for a ten-thousand block, we'll say. A SIP call is placed, and wants to claim a number within that ten-thousand block. The proposed system could work in at least two ways. In the first way, Verizon will have delegated to the calling UA a sub-credential covering only the specific number, and the calling UA will actually provide a signature itself before sending the call. In the second way, Verizon could operate some kind of service, effectively like a SIP proxy, that the caller would send the call through; Verizon would in some service-specific way authenticate the caller, and then sign the call with their ten-thousand block credential if the On the verification side, when a call comes in, a verification service (which might be implemented at a intermediary, or even in an end device potentially) will compare the credential that created the signature with the telephone number asserted in the From header field. If they match, or more precisely if the credential has a scope that includes the number in question, then provided the signature verifies then the identity will be presented as a verified identity. So to your points: >Similarly, what is the rule for when it's OK that entity 'A' assert >identity (e.g., phone number) 'b'? Some seem obvious, but not all. For >example: > > Case 1: numbering plan administrator has assigned identity 'b' to >carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. > Case 2: numbering plan administrator has assigned identity 'b' to >carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. > Person 'C' grants to person 'A' permission to identify itself >as 'b'. > Case 3: numbering plan administrator has assigned identity 'b' to >carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. > Person 'C' grants to person 'A' permission to identify itself >as 'b'; with some constraints (e.g., only at night, or only > for 1 day, or only to invoke certain services or call certain >numbers). > >In case 1 it is OK for 'A' to identify itself as 'b'. Provided X has given the appropriate credential to A, or is otherwise willing to sign their request, then yes. >In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on >whether there are restrictions on "sub-assignment" of numbers and if so, >whether 'C' meets them. Depending on how the credential system works, there are a variety of ways to meet requirements along these lines. If A has a certificate giving them authority for b, they could potentially delegate some of the authority to a certificate held by C, and C could then use that authority to place a call for b. Again, just an example. There are potentially other mechanisms with alternative delegation properties. >In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending >both on whether 'C' had authority to 'sub-assign' identity 'b', and >whether the other restrictions specified by 'C' were met. Who would >check? The ability to impose constraints like this is something that could be designed into the credential mechanism. While that's not impossible, it's certainly not the first case that would be on our plate in the proposed STIR work. Ultimately, again with something like a certificate issued to C, attributes in the cert could indicate these parameters, and a verification service could verify them when A uses the cert. Or if we assume Verizon manages all signatures for this ten-thousand block, perhaps C would have some web interface to Verizon that lets them articulate this policy and designate very narrow powers to A. In the latter case, this would be more of a question of application behavior than standards. But again, I think these sorts of policies would be something we'd consider after nailing down more basic cases. Jon Peterson Neustar, Inc. > >Cheers, > >tim > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Rosen, Brian >Sent: Wednesday, June 19, 2013 8:52 AM >To: stir@ietf.org >Subject: [stir] Do we agree on the basics? > >A lot of our discussion is focussed on where certs are found. I want to >make sure that we agree on the basics, because where certs are found is >pretty far down the list of things to agree on. > >So, do we agree: >1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The >APPROACH we're going to use is to verify the IDENTITY of the SOURCE of >the call, because we believe that spoofing identity or non providing >identity is the way the bad calls are being placed. >3. The METHOD we're going to use is to pick some data from the call and >sign or encrypt it in a way that a downstream entity can verify that the >information is valid 4. The CREDENTIALS we're going to use, for >identities that are telephone numbers, is based on delegation of the >number, rooted in the national numbering authority. For identities that >are domain based, the credentials are based on the domain entry in the >DNS. >5. We think we need two MECHANISMS, an in-band mechanism that has the >originating device or service provider signing information and carries >the signature in the signaling. The other is some out of band mechanism >that involves some new database or service that gets written by the >originating device or service provider and checked by some downstream >entity. The latter mechanism is needed to allow the identity to be >assured even if the information or signature from the in band mechanism >is lost (such as when the call goes through an SS7 hop). >6. The credentials (4) are the same in both mechanisms (5) > > >That doesn't say things like where the certs are or what is signed, or >what the out of band mechanism does. > >So, I ask, do you agree with that? > >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 hadriel.kaplan@oracle.com Wed Jun 19 10:47: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 73FC321F9B8F for ; Wed, 19 Jun 2013 10:47:28 -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 jHKDugVSZ0Vd for ; Wed, 19 Jun 2013 10:47:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3739521F9AD9 for ; Wed, 19 Jun 2013 10:47:23 -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 r5JHlIm6003170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 17:47:19 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 r5JHlHT4018794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 17:47:18 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JHlHSk018781; Wed, 19 Jun 2013 17:47:17 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 10:47:17 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 19 Jun 2013 13:47:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:47:28 -0000 Yup, though I still think you'd want to do that for an artificial node = name like '_cid.foo.com' or whatever, rather than for 'foo.com'. -hadriel On Jun 19, 2013, at 1:23 PM, "Lee, Yiu" = wrote: > Can we get the dnskey record and verify it by the ds record and forget = the > whole CA thing? >=20 > On 6/19/13 1:12 PM, "Hadriel Kaplan" = wrote: >=20 >> We have can't just look up the DNS domain key of 'foo.com' to get the >> certificate > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Wed Jun 19 10:58: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 80A7221F9DD1 for ; Wed, 19 Jun 2013 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 DlL5rNHaAoJO for ; Wed, 19 Jun 2013 10:58:49 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0C21F9DCF for ; Wed, 19 Jun 2013 10:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371664908; x=1687019469; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=LY89MVJecN ne5LSTp7pbtXBqtYPtCdQcely2XRYn4Rw=; b=Iw9RUrEU/T9Ibj8vyCkfWKFf03 SJ/OTtgFa5crYzbznOcnFwhWxlO3uSVqqxDNIojNSLDKX6qb6y2sFTU7JuNw== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25374626; Wed, 19 Jun 2013 14:01:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:58:46 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlCAAEiZgIAAMYgAgAAHZoA= Date: Wed, 19 Jun 2013 17:58:45 +0000 Message-ID: <750F4E38-E126-4BE0-AD13-6B6EEF866DA3@neustar.biz> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> In-Reply-To: <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ucOkQFkfAIBwjuV8xff8Sw== Content-Type: text/plain; charset="Windows-1252" Content-ID: <0CF5F57BD71E9F49A4ABB0289A42287D@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Michael Hammer , "pp3129@att.com" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 17:58:53 -0000 To a certain extent, I agree, but it's also the case that we get a hair bal= l out of solving every problem before we start work. To me, the problems with EKR's idea, which I actually like quite a bit are: a) Only the origination can write the record. This might possibly be fixab= le in some cases (SIP->SS7 GW is owned by a service provider who has the nu= mber delegated to it, even though it delegated the number downstream). But= in a generic transit network case, it wouldn't work. With in-band, the an= y provider in the path can verify. But only the termination entity (the on= e who owns the credential) can validate. b) It depends (for stopping robocalling, vishing and swatting) on being abl= e to discover the credentials of the termination by the origination. That = requires a public database of TN to cert. I think the PERCEIVED difficulti= es of doing that doom deployment in any interesting timeframe. I think man= y national regulators and national carriers will refuse to allow it. I thi= nk many privacy advocates will object enough to slow deployment unacceptabl= y. The problems with the alternate idea (SIP->SS7 writes, SS7->SIP queries, re= store the in band information) is that it has a more limited applicability,= and must have a central DB. There is another idea I've had for the problem of PSTN. First of all, not= e that if the SIP->SS7 GW checked identity in band, it fixes the problem. = It doesn't have to be the termination device or carrier. Further, if ANY e= ntity in the path checks, it fixes the problem. That means SIP origination= , PSTN termination can be addressed if we have at least one good SP in the = path. The idea is that if the SS7->SIP GW doesn't find the record, we could issue= it a cert that it could use to create a signature from that point forward.= That cert would only say "I don't know what happened before I got the cal= l, but from here on, the identities were =85". That helps adoption some. = It doesn't fix a spoofed ID that started in the SS7 network. On Jun 19, 2013, at 1:32 PM, Hadriel Kaplan wro= te: >=20 > On Jun 19, 2013, at 10:34 AM, "Rosen, Brian" wr= ote: >=20 >> Of course, like most of us, you are an engineer, so you want to see that= there is at least one solution that could work before you even want to see= something in a charter. So, EKR proposed one solution where the source wr= ites a data record in a database encrypted for the termination. All that d= epends on is the source and destination identities. Ignoring whether you t= hink we can deploy it, it does solve the problem. >=20 > So does putting the info on a piece of paper, rolling it up, attaching th= e roll to the leg of a carrier pigeon, and pushing the pigeon out the windo= w. But I don't think we can ignore that such a solution isn't deployable. = (mostly because there aren't enough qualified pigeons) >=20 > I'm not trying to be difficult - I'm worried because in the BOFs that I'v= e been to before, whether a problem is solvable in a useful/deployable fash= ion is often a criteria for getting a Working Group created. Or instead du= ring the BOF we get bogged down with lots of microphone discussion about th= e viability of solutions, and run out of time resulting in a request for an= other BOF before getting a Working Group. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Wed Jun 19 11:00: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 E0FAA21F9BB0 for ; Wed, 19 Jun 2013 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.265, 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 b8NoDbuup3GZ for ; Wed, 19 Jun 2013 11:00:54 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 2F73121F9AC3 for ; Wed, 19 Jun 2013 11:00:49 -0700 (PDT) Received: (qmail 9045 invoked by uid 0); 19 Jun 2013 18:00:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 19 Jun 2013 18:00:48 -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=wCgsbuuNdun0sR0b+bKV5wfj2WTI2Uz0Ua/fVzgJYLU=; b=BZ3aRv2yuuCbsPTEOuzWnblLBNvu9GBZIcVbBVfSsTpXtNnJ0e/2XxpSe4F+MNr6jVKjXvdjYtdt/7pdZmuId02x4p8UR86rEXSRWZs/Z5SKMz99k8T40nT2KL7qiOhU; Received: from [72.66.111.124] (port=52585 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UpMga-0007Qt-1n for stir@ietf.org; Wed, 19 Jun 2013 12:00:48 -0600 From: "Richard Shockey" To: References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 19 Jun 2013 14:00:45 -0400 Message-ID: <00e101ce6d16$ed211740$c76345c0$@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: AQHAjWxiYKyeFeQ0QFi1FrZzZNPRqwI7dS/0mUcIjEA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:00:59 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Wednesday, June 19, 2013 11:08 AM To: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? Brian, Thanks for a timely summary. I have some questions I've been hoping would become clear by monitoring the discussion, that so far haven't. Questions re. scope: -------------------- #1: Is the scope limited to _only_ identities that are or imbed, E.164 numbers? [RS> ] IMHO E.164 for now. I, for one, will never support any charter that has "boil the ocean" goals and objectives. #2: Does the scope include identities that are or imbed, numbers structured per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers)? [RS> ] Excellent question. IMHO it does but don't get me started on SMS800.com. I do believe they will have to be involved at some point since those numbers are absolutely vital to business. #3: Does the scope include identities that are or imbed, national numbers? [RS> ] Please clarify.. I don't understand. General Question: ----------------- #4: Is there any actual data behind this initiative? I don't recall seeing any numbers (e.g., how often do various types of bad things, happen; what damage is done; is it on the rise or decline). [RS> ] Right now the Federal Trade Commission is reporting 200,000 complaints per month to their agency alone on issues related to Call Spoofing. I don't have exact figures on the FCC complaint lines but I would easily bet its #1 or #2 as well. The CRTC in Ottawa is reporting 50% of their complaints etc. It not just the criminal fraud issues it's the violation of the do not call lists etc and a host of other Telephony Denial of Service Attacks on enterprises and even PSAP's. There is ample evidence of a broad spectrum problem. Henning gave a useful presentation several weeks ago here in DC I'll let him post the URL. I don't recall any assessment of how these things are being done (just assumptions that they're facilitated by spoofing caller ID in a VoIP call origination). [RS> ] [RS> ] Especially from Call Gateways operated by some carrier Wholesale divisions. Yes, I know there are web sites you can go to that let you do exactly that. But do we know that that's how this mischief is being done? What if it's being initiated on a circuit switched PBX connected into the POTS network via a PRI, and the culprits are leveraging gaps in the interworking of ISUP and SIP to go undetected? If it's knowable we ought to try and know, so that we fix the right problem. I don't recall any analysis of the [in]adequacy of currently defined mechanisms. Why for example does transitive trust seem to work in the PSTN but not in SIP? I'm not really trying to invite pontification. I'm asking has any actual investigation been done, and if so where are the results? A list of URLs would be great. No offense intended with respect to the interesting technical discussions already taking place, but in order to motivate deployment _somebody_ is going to have to do this. Regarding the discussion below: ------------------------------- On point #2, can you clarify what is meant by "verify the identity of the source"? What I'm imagining is something like (a) verifying that the calling identity is "valid"; and (b) verifying that the calling UA has the "right" to claim that identity for the purpose of initiating the call in question. Is that roughly it? If so, can you step through how that validity check would work? It's kind of a big leap to see how "pick[ing] some data from the call and sign[ing] it", achieves those objectives. Similarly, what is the rule for when it's OK that entity 'A' assert identity (e.g., phone number) 'b'? Some seem obvious, but not all. For example: Case 1: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. Case 2: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as 'b'. Case 3: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as 'b'; with some constraints (e.g., only at night, or only for 1 day, or only to invoke certain services or call certain numbers). In case 1 it is OK for 'A' to identify itself as 'b'. In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on whether there are restrictions on "sub-assignment" of numbers and if so, whether 'C' meets them. In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both on whether 'C' had authority to 'sub-assign' identity 'b', and whether the other restrictions specified by 'C' were met. Who would check? Cheers, tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, June 19, 2013 8:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. So, I ask, do you agree with that? 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 chris_wendt@cable.comcast.com Wed Jun 19 11:04: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 BF5C721F9AE7 for ; Wed, 19 Jun 2013 11:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 cCl5optkkfB0 for ; Wed, 19 Jun 2013 11:04:32 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A09A621F9E30 for ; Wed, 19 Jun 2013 11:04:29 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78186460; Wed, 19 Jun 2013 12:03:51 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 19 Jun 2013 14:04:25 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 14:04:25 -0400 From: "Wendt, Chris" To: Hadriel Kaplan Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObRduwSlmpMZitUyhAdakrHC3YQ== Date: Wed, 19 Jun 2013 18:04:24 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD9419287F1@PACDCEXMB01.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "Lee, Yiu" Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:04:37 -0000 Or overload something like sbc.foo.com for both SIP routing as well as publ= ic key distribution for validating signed SIP URI, for example. ;) On Jun 19, 2013, at 1:47 PM, Hadriel Kaplan wrote: >=20 > Yup, though I still think you'd want to do that for an artificial node na= me like '_cid.foo.com' or whatever, rather than for 'foo.com'. >=20 > -hadriel >=20 >=20 > On Jun 19, 2013, at 1:23 PM, "Lee, Yiu" wrote= : >=20 >> Can we get the dnskey record and verify it by the ds record and forget t= he >> whole CA thing? >>=20 >> On 6/19/13 1:12 PM, "Hadriel Kaplan" wrote: >>=20 >>> We have can't just look up the DNS domain key of 'foo.com' to get the >>> certificate >> _______________________________________________ >> 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 richard@shockey.us Wed Jun 19 11:07: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 5E46F21F9E3C for ; Wed, 19 Jun 2013 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.215 X-Spam-Level: X-Spam-Status: No, score=-100.215 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_00=-2.599, FRT_PENIS1=3.592, 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 l3YqNJ9zjdG7 for ; Wed, 19 Jun 2013 11:07:08 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 436CB21F9A24 for ; Wed, 19 Jun 2013 11:06:55 -0700 (PDT) Received: (qmail 22319 invoked by uid 0); 19 Jun 2013 18:06:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 19 Jun 2013 18:06:30 -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=x0X5eCqGMNuiZPXLsVxVf9IQBp5lfXZY75lyBp45SHA=; b=WEWgLCWLM5gytPwHjVrBjPql2e1ahnKjuBoft/O54uZSHZUqyfQTLkE+Fzr7XneL8D/nBDNGVtXjcu0gsPsqadpdaeMMUP+MudZzpfw9fSjTVrNu8+rTWnR9xmT1z5+P; Received: from [72.66.111.124] (port=52602 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UpMm5-0003TW-MJ for stir@ietf.org; Wed, 19 Jun 2013 12:06:30 -0600 From: "Richard Shockey" To: References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> <38726EDA2109264987B45E29E758C4D60495F32D@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60495F32D@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Wed, 19 Jun 2013 14:06:27 -0400 Message-ID: <00e201ce6d17$b8bf4020$2a3dc060$@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: AQHAjWxiYKyeFeQ0QFi1FrZzZNPRqwI7dS/0AipDUIaZNbmDEA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:07:13 -0000 I know Penn. This is an excellent example of the corner case of legitimate manipulation in the public interest. I'm sure we can address this, but at some point the regulators themselves are going to have to look at the problem with a different view. What I'm sure of is the IETF has no magic bullet here. We can only provide tools. In order to look at a comprehensive solution there will have to be some recognition among the regulators that they have a big tool box as well and it contains a pretty big hammer. If you look at the Truth in Caller ID act its badly written and functionally useless since enforcement depends on the notion of "intent to defraud" which is difficult to prove. What would have been more useful is to ban Caller ID spoofing entirely with the exception of a specific "certificate of need" such as the use case you describe and the others we are all aware of. Another option is the case of the TCPA permit a private right of action against the violators. That private right of action was vital in controlling the Junk fax problem in the mid 90's. www.fcc.gov/cgb/policy/TCPA-Rules.pd At some point the regulators and the legislators will have to follow the wisdom of Captain Spock, "the needs of the many outweigh the needs of the few" I could also quote Jeremy Bentham but that might be going over the top even for me. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Wednesday, June 19, 2013 11:15 AM To: Dwight, Timothy M (Tim); Rosen, Brian; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? +1 to the concern about non-VoIP based spoofing and the issue of legitimate use of a number assigned to another party. To be specific, lots of companies contract with call centers for telemarketing. They want the calling party number to show the toll free number of the company with the product, not the telemarketer. 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 Dwight, Timothy M (Tim) Sent: Wednesday, June 19, 2013 11:08 AM To: Rosen, Brian; stir@ietf.org Subject: Re: [stir] Do we agree on the basics? Brian, Thanks for a timely summary. I have some questions I've been hoping would become clear by monitoring the discussion, that so far haven't. Questions re. scope: -------------------- #1: Is the scope limited to _only_ identities that are or imbed, E.164 numbers? #2: Does the scope include identities that are or imbed, numbers structured per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers)? #3: Does the scope include identities that are or imbed, national numbers? General Question: ----------------- #4: Is there any actual data behind this initiative? I don't recall seeing any numbers (e.g., how often do various types of bad things, happen; what damage is done; is it on the rise or decline). I don't recall any assessment of how these things are being done (just assumptions that they're facilitated by spoofing caller ID in a VoIP call origination). Yes, I know there are web sites you can go to that let you do exactly that. But do we know that that's how this mischief is being done? What if it's being initiated on a circuit switched PBX connected into the POTS network via a PRI, and the culprits are leveraging gaps in the interworking of ISUP and SIP to go undetected? If it's knowable we ought to try and know, so that we fix the right problem. I don't recall any analysis of the [in]adequacy of currently defined mechanisms. Why for example does transitive trust seem to work in the PSTN but not in SIP? I'm not really trying to invite pontification. I'm asking has any actual investigation been done, and if so where are the results? A list of URLs would be great. No offense intended with respect to the interesting technical discussions already taking place, but in order to motivate deployment _somebody_ is going to have to do this. Regarding the discussion below: ------------------------------- On point #2, can you clarify what is meant by "verify the identity of the source"? What I'm imagining is something like (a) verifying that the calling identity is "valid"; and (b) verifying that the calling UA has the "right" to claim that identity for the purpose of initiating the call in question. Is that roughly it? If so, can you step through how that validity check would work? It's kind of a big leap to see how "pick[ing] some data from the call and sign[ing] it", achieves those objectives. Similarly, what is the rule for when it's OK that entity 'A' assert identity (e.g., phone number) 'b'? Some seem obvious, but not all. For example: Case 1: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. Case 2: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as 'b'. Case 3: numbering plan administrator has assigned identity 'b' to carrier 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. Person 'C' grants to person 'A' permission to identify itself as 'b'; with some constraints (e.g., only at night, or only for 1 day, or only to invoke certain services or call certain numbers). In case 1 it is OK for 'A' to identify itself as 'b'. In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on whether there are restrictions on "sub-assignment" of numbers and if so, whether 'C' meets them. In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both on whether 'C' had authority to 'sub-assign' identity 'b', and whether the other restrictions specified by 'C' were met. Who would check? Cheers, tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, June 19, 2013 8:52 AM To: stir@ietf.org Subject: [stir] Do we agree on the basics? A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. So, do we agree: 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). 6. The credentials (4) are the same in both mechanisms (5) That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. So, I ask, do you agree with that? 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 From brian.rosen@neustar.biz Wed Jun 19 11:13: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 8BF8921F9E79 for ; Wed, 19 Jun 2013 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 9BVYezUKoFu0 for ; Wed, 19 Jun 2013 11:13:52 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9421F9E81 for ; Wed, 19 Jun 2013 11:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371665581; x=1687024818; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=n2rqHH3po9 R0Cs8u1ZYTcHB6VOAVB0g1dI7yaAwiQuA=; b=C/ArkoQHMPTjLAtN1aAI/HC0Xh ZJGJxZSA2BKkkTTUtafWUt3CwHlbZFvgeV35DFo03s8WCgJtrp91e1soW2WQ== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21175957; Wed, 19 Jun 2013 14:13:00 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 14:13:45 -0400 From: "Rosen, Brian" To: "PFAUTZ, PENN L" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9EAqggAAUpcCAAHXuAA== Date: Wed, 19 Jun 2013 18:13:44 +0000 Message-ID: <4770E43A-22A6-447D-AC9C-BFE2D515504C@neustar.biz> References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> <38726EDA2109264987B45E29E758C4D60495F32D@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60495F32D@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7bmvhGUM0nPjugiyjmgVHg== Content-Type: text/plain; charset="us-ascii" Content-ID: <2FC6FDABDA848E4CB35A94E93782AFA1@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:13:56 -0000 You get the idea that if we have a chain of delegations, we have a mirror c= hain of certs. The enterprise gets a cert from his SP covering his number.= He can then issue a cert to the call center authorizing them to use its n= umber. It's one more delegation and one more link in the chain. Note that= this is analogous to the SP signing with its cert a call from the enterpri= se. Even if it has delegated the number, it can, if it wishes, sign the he= ader. It probably would want to police such calls to make sure they are fr= om who they say they are from before it signs, of course. Brian On Jun 19, 2013, at 11:14 AM, "PFAUTZ, PENN L" wrote: > +1 to the concern about non-VoIP based spoofing and the issue of legitima= te use of a number assigned to another party. To be specific, lots of compa= nies contract with call centers for telemarketing. They want the calling pa= rty number to show the toll free number of the company with the product, no= t the telemarketer. >=20 > Penn Pfautz > AT&T Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of D= wight, Timothy M (Tim) > Sent: Wednesday, June 19, 2013 11:08 AM > To: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? >=20 > Brian, >=20 > Thanks for a timely summary. I have some questions I've been hoping woul= d become clear by monitoring the discussion, that so far haven't. >=20 > Questions re. scope: > -------------------- > #1: Is the scope limited to _only_ identities that are or imbed, E.164 n= umbers? > #2: Does the scope include identities that are or imbed, numbers structu= red per Rec. E.164 that aren't end point identifiers (e.g., toll free numbe= rs)? > #3: Does the scope include identities that are or imbed, national number= s? >=20 > General Question: > ----------------- > #4: Is there any actual data behind this initiative? I don't recall see= ing any numbers (e.g., how often do various types of bad things, happen; wh= at damage is done; is it on the rise or decline). I don't recall any asses= sment of how these things are being done (just assumptions that they're fac= ilitated by spoofing caller ID in a VoIP call origination). Yes, I know th= ere are web sites you can go to that let you do exactly that. But do we kn= ow that that's how this mischief is being done? What if it's being initiat= ed on a circuit switched PBX connected into the POTS network via a PRI, and= the culprits are leveraging gaps in the interworking of ISUP and SIP to go= undetected? If it's knowable we ought to try and know, so that we fix the= right problem. I don't recall any analysis of the [in]adequacy of current= ly defined mechanisms. Why for example does transitive trust seem to work = in the PSTN but not in SIP? >=20 > I'm not really trying to invite pontification. I'm asking has any actual= investigation been done, and if so where are the results? A list of URLs = would be great. No offense intended with respect to the interesting techni= cal discussions already taking place, but in order to motivate deployment _= somebody_ is going to have to do this. >=20 >=20 > Regarding the discussion below: > ------------------------------- > On point #2, can you clarify what is meant by "verify the identity of the= source"? What I'm imagining is something like (a) verifying that the call= ing identity is "valid"; and (b) verifying that the calling UA has the "rig= ht" to claim that identity for the purpose of initiating the call in questi= on. Is that roughly it? If so, can you step through how that validity che= ck would work? It's kind of a big leap to see how "pick[ing] some data fro= m the call and sign[ing] it", achieves those objectives. >=20 > Similarly, what is the rule for when it's OK that entity 'A' assert ident= ity (e.g., phone number) 'b'? Some seem obvious, but not all. For example= : >=20 > Case 1: numbering plan administrator has assigned identity 'b' to carri= er 'X'. Carrier 'X' has assigned identity 'b' to person 'A'. > Case 2: numbering plan administrator has assigned identity 'b' to carri= er 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. > Person 'C' grants to person 'A' permission to identify itself a= s 'b'. > Case 3: numbering plan administrator has assigned identity 'b' to carri= er 'X'. Carrier 'X' has assigned identity 'b' to person 'C'. > Person 'C' grants to person 'A' permission to identify itself a= s 'b'; with some constraints (e.g., only at night, or only > for 1 day, or only to invoke certain services or call certain n= umbers). >=20 > In case 1 it is OK for 'A' to identify itself as 'b'. > In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on = whether there are restrictions on "sub-assignment" of numbers and if so, wh= ether 'C' meets them. > In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending bot= h on whether 'C' had authority to 'sub-assign' identity 'b', and whether th= e other restrictions specified by 'C' were met. Who would check? >=20 >=20 > Cheers, >=20 > tim >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Wednesday, June 19, 2013 8:52 AM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to = make sure that we agree on the basics, because where certs are found is pre= tty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The = APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the = call, because we believe that spoofing identity or non providing identity i= s the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign or encrypt it in a way that a downstream entity can verify that the inf= ormation is valid 4. The CREDENTIALS we're going to use, for identities tha= t are telephone numbers, is based on delegation of the number, rooted in th= e national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the ori= ginating device or service provider signing information and carries the sig= nature in the signaling. The other is some out of band mechanism that invo= lves some new database or service that gets written by the originating devi= ce or service provider and checked by some downstream entity. The latter m= echanism is needed to allow the identity to be assured even if the informat= ion or signature from the in band mechanism is lost (such as when the call = goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > 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 From jon.peterson@neustar.biz Wed Jun 19 11:18: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 39F7621F9E9C for ; Wed, 19 Jun 2013 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 i6Bux5Bn-dul for ; Wed, 19 Jun 2013 11:18:50 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0108B21F9B12 for ; Wed, 19 Jun 2013 11:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371665869; x=1687024818; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=iZYjy0XkvN o9j13CnwakMpBXu6G3SFU2ByeSBhvOH44=; b=lvb6+CFsoPpBL9c5xVVZtC3/60 fEnhZjCfIPpLjy66EfttTUXtcOcE4rQDhzoJGke/hds5SawhgBqy1+bMgYvQ== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21176225; Wed, 19 Jun 2013 14:17:48 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 14:18:34 -0400 From: "Peterson, Jon" To: "Lee, Yiu" , "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHOaJxVI+SntM7IA0Gg0AdKCtvNaJk3aKkAgAG9EACAAJEAgP//mGKAgAElawD//6FkgIAAmBwA///JN4AAMejCAAApJjoAAAhMdYAAAGdqgP//mfUA Date: Wed, 19 Jun 2013 18:18:33 +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.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: lEGBfKKGRM9rAJEjoIS5Yg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:18:54 -0000 I think this list has gotten bogged down in the question of how to download credentials at the verification service. I sense this is motivated by a feeling that we are going to have a beauty contest and pick one way to download credentials, and everyone would like it to be their favorite way. I don't really look at the STIR problem that way, though. I don't really care, at the end of the day, how a verification service downloads credentials. I don't think we even need to arrival a single way of doing it. The Identity-Info header of RFC4474 gives verification services a hint of where they could acquire credentials. Nothing about RFC4474 assumes though that the verification service doesn't already have a public key for the auth service, or that the verification service doesn't have its own means of looking up credentials in a store, say (see Step 1 of Section 6 of RFC4474). Dereferencing the Identity-Info is not in that strict sense required. Even when there verification service does dereference the URI in Identity-Info to get a credential, RFC4474 leaves the door pretty wide open for what protocols can be used: it does specify HTTP as MTI, but this is not exclusive. We discussed using SIP itself (with a fetch SUB), CID for multipart MIME and several other options. I can even imagine using a DNS URI for this, especially for a DANE or DANE-like case where you want to tip off the verifier that the public key can be found in the DNS. Again, the presence of a DNS URI in Identity-Info would just be a hint, a "in case you didn't know, my public key is in a DANE record." Maybe some verification services wouldn't need that hint as they always check the DNS for a public key. So you could argue even that at an over-the-wire level, we wouldn't even need to change Identity-Info to support using the DNS as a way to access credentials. What would need to change, of course, is the logic used by auth/verification services to handle telephone numbers, and for DANE-like cases, to check reference integrity. This, I think, is where the actual STIR work should lie. I don't think we should try to legislate a one true way that services must make credentials available. We should introduce flexibility here, even if it means perhaps having two MTIs for Identity-Info URI schemes instead of one. But we shouldn't get caught up on what protocol you use to fetch credentials. Jon Peterson Neustar, Inc. On 6/19/13 10:23 AM, "Lee, Yiu" wrote: >Can we get the dnskey record and verify it by the ds record and forget the >whole CA thing? > >On 6/19/13 1:12 PM, "Hadriel Kaplan" wrote: > >>We have can't just look up the DNS domain key of 'foo.com' to get the >>certificate From fas_vm@surguttel.ru Wed Jun 19 11:34: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 26FE121F9E94 for ; Wed, 19 Jun 2013 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[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 sxAqbVQ7QCGM for ; Wed, 19 Jun 2013 11:34:27 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2E121F9E92 for ; Wed, 19 Jun 2013 11:34:26 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 232AF514C95; Thu, 20 Jun 2013 00:33:42 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.74]) by mail.s86.ru (Postfix) with ESMTPA id EC303514A57 for ; Thu, 20 Jun 2013 00:33:38 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: Date: Thu, 20 Jun 2013 00:20:15 +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 130619-0, 19.06.2013), Outbound message X-Antivirus-Status: Clean Subject: [stir] Some notes... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:34:33 -0000 Dear All, Why not hop-to-hop? This is how banking system works. Each pair exchange their public keys, and promise not to allow spoofed calls, not to modify messages unless really needed, not to abuse otherwise. For each message, each party verifies a signature, modifies a message as needed (e.g. from-tag and to-tag are modified by B2BUA), and re-signs. Combining From-tag with From-name and From-URI into single header is actually incidentally, and unlucky. They belong to different entities. Otherwise, there will be someone who doesn't want to join existing trust network (but to start his/her own). So we return to the "public ENUM" problem. As I noted, most websites use self-signed certificates for HTTPS, and few use VeriSign-issued. No trust networks. I suggest modifying the WG Charter. See also accompanying message... Regards, Anton. From fas_vm@surguttel.ru Wed Jun 19 11:34: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 53EA821F9E92; Wed, 19 Jun 2013 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.472 X-Spam-Level: X-Spam-Status: No, score=0.472 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_INVITATION=-2, 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 wzy7R+ddbtOx; Wed, 19 Jun 2013 11:34:27 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A21021F9E91; Wed, 19 Jun 2013 11:34:26 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id F2E71514FBC; Thu, 20 Jun 2013 00:33:42 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.74]) by mail.s86.ru (Postfix) with ESMTPA id 3454F514A88; Thu, 20 Jun 2013 00:33:39 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: , Date: Thu, 20 Jun 2013 00:28:09 +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 130619-0, 19.06.2013), Outbound message X-Antivirus-Status: Clean Subject: [stir] SIP Header semantics X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:34:33 -0000 Dear All, I want to express my opinion about SIP header and some associated semantics. Some definitions: Identity: a person, a juristic person, an organization without legal personhood, a public body, a department of an organization or of a sole-owned business, a person acting on behalf of anything above (as an agent), or a robot working on behalf of anything/anyone above. Or, something identified by AOR (although AORs may be aliased). RA: Roaming address, as opposed to AOR. It may be IP-based, GRUU, LRUU, etc. Call is a chain of dialogs, separated by B2BUAs and gateways. Caller and callee are parties of the call, but UAC and UAS are parties of the dialog. Call forwarding is a change of callee AOR; it is different from call routing. Call forwarding does not imply any changes in dialogs (it may be handled by a proxy), but it changes the callee. Call routing: mapping AOR->RA. It is different from un-aliasing AORs. SIP headers and parameters follow... From-name, from-URI: the caller. These do not change when the call is forwarded. Connection is established between the caller and the callee. From-name is supplied either by the caller or by the network. From-URI acts both as an anonymity flag and as caller's AOR. Contact (in request) is UAC's RA. It reflects the last B2BUA (or caller, if there is no B2BUA). Contact (in 180, 182, 200) is UAS's RA. Contact (in 3xx) is forwarded-to AOR. Contact (in 4xx-6xx) is something yet different. Contact (in 181) thus has no sense and should not be used. To-name, to-URI: the callee. Actually (esp. in responses), the last forwarded-to or answering party. To-URI in responses is also an anonymity flag for answering or forwarding party. Otherwise it is an AOR. History-Info contains AOR of the forwarding party. The forwarding party really has no RA. Subject: for conference invitations, this is party-specific, rather than conference-wide (cf. SDP "s=" line) Any comments? Regards, Anton From brian.rosen@neustar.biz Wed Jun 19 11:41: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 8C29521F9C03 for ; Wed, 19 Jun 2013 11:41:35 -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 hNlRWS-vyWwd for ; Wed, 19 Jun 2013 11:41:31 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF521F9DB8 for ; Wed, 19 Jun 2013 11:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371667223; x=1687024818; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=J83iKaXNKu bcD4Oxul5kRxSXtbCXfG+5ziJf4j87fnE=; b=kLzwm9Um+csVF7q2BWtRRD/R9j gJnHyNa75NkkkpwkDLOVgZQjw4lvAru7nEplvkYPW3+KcqeNZlYFFpAExP4g== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21177266; Wed, 19 Jun 2013 14:40:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 14:41:08 -0400 From: "Rosen, Brian" To: "" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9ogiA Date: Wed, 19 Jun 2013 18:41:07 +0000 Message-ID: <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> In-Reply-To: <51C1E99A.6080507@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Q9nH0gAa/IwDb9kqwYg4fw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71D8F02DD57B694BAE38245CC0895692@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 18:41:35 -0000 Just to be clear, the reason why I want to have the second mechanism sooner= rather than later is that essentially all interconnect between certificate= d carriers is via SS7. If we don't solve that problem, it won't work. The counter argument is that by the time we deploy anything, that won't be = true. I don't believe that. Brian On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: > On 6/19/2013 10:21 AM, Rosen, Brian wrote: >> To be fair, there are some scenarios other than SS7 links where the info= rmation is lost. If we go for an SS7-only solution, we don't cover those c= ases. The mechanisms may be able to be used in other environments. >=20 > What scenarios, specifically? >=20 >=20 >> I don't know why you think that we have "vanishingly small success for t= he SS7/SIP queries". >=20 >=20 > This is Transition 101. In the absence of an explicit indicator of suppo= rt, checking for the data is blind; a query must be done every time, whethe= r it will succeed or not. >=20 > Because there is not universal cut-over event, adoption is incremental. = The world starts with zero adoption and tries to move in a positive directi= on. >=20 > Until adoption is very widespread, the likelihood that a query will succe= ed is small because the proportion of adopters doing signing is small. Van= ishingly small. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dhc@dcrocker.net Wed Jun 19 11:58: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 9C09621F9E05 for ; Wed, 19 Jun 2013 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 GxM8tPJeRN2i for ; Wed, 19 Jun 2013 11:58:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADC3E21F9E13 for ; Wed, 19 Jun 2013 11:58:54 -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 r5JIwoPv023774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 11:58:54 -0700 Message-ID: <51C1FF5A.7020202@dcrocker.net> Date: Wed, 19 Jun 2013 11:58:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> In-Reply-To: <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> 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, 19 Jun 2013 11:58:54 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out of band 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, 19 Jun 2013 18:58:59 -0000 On 6/19/2013 11:41 AM, Rosen, Brian wrote: > Just to be clear, the reason why I want to have the second mechanism sooner rather than later is that essentially all interconnect between certificated carriers is via SS7. If we don't solve that problem, it won't work. > > The counter argument is that by the time we deploy anything, that won't be true. I don't believe that. I don't recall commenting on the timing for specifying this, but rather that it be encapsulated as the gateway-specific mechanism that it is. And that attention be paid to the classic adoption-barrier problem of having the receive side be forced to do a query everytime and blindly and with very small success rates in the early stages of adoption (if not longer.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pp3129@att.com Wed Jun 19 12:12: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 6472521F9EDC for ; Wed, 19 Jun 2013 12:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IOe+x7+x-eVE for ; Wed, 19 Jun 2013 12:11:57 -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 B665B21F9EC9 for ; Wed, 19 Jun 2013 12:11:57 -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 d7202c15.76753940.691281.00-529.1914546.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 19 Jun 2013 19:11:57 +0000 (UTC) X-MXL-Hash: 51c2027d45bd578d-43c968284d773626cbfaf4a51f32e9c3ee0e0c7b 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 97202c15.0.691210.00-461.1914337.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 19 Jun 2013 19:11:57 +0000 (UTC) X-MXL-Hash: 51c2027d0bd88294-c2a33f5d2e4cdad75621b74fc1fb8054e2baed0e 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 r5JJBoiA007799; Wed, 19 Jun 2013 15:11:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5JJBguF007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 15:11:46 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 19 Jun 2013 19:11:24 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 15:11:31 -0400 From: "PFAUTZ, PENN L" To: "dcrocker@bbiw.net" , "Rosen, Brian" Thread-Topic: [stir] Out of band Thread-Index: AQHObR8Zd7sgFvFRSEKO7xRvj3lVppk9ZNLg Date: Wed, 19 Jun 2013 19:11:30 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> <51C1FF5A.7020202@dcrocker.net> In-Reply-To: <51C1FF5A.7020202@dcrocker.net> 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.20.146] X-AnalysisOut: [v=2.0 cv=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Yh5l8hSFW] X-AnalysisOut: [2wA:10 a=48vgC7mUAAAA:8 a=k7Ga1wGzAAAA:8 a=dfzINpKMQTqqw43] X-AnalysisOut: [dMTIA:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=x3I_HB9Tk8MA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=OHLF3jd414l0khi2:21 a=C_FLOu0DOQEL] X-AnalysisOut: [UyKQ:21] Cc: "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 19:12:03 -0000 I don't want to drag us too far off course but would offer the following pe= rspective on the timing of SIP interconnection and what we're trying to do = here: SS7 interconnection persists where there are SS7 endpoints. Where you have = an SS7 originating point/network you are not going to get either inband or = out of band to work (can't encode for inband; can't post for out of band.) = Likewise, where you have an SS7 served terminating point/network you won't = get it either (can't access either validation mechanism; can't show the re= sult to the called party). That's the bad news. The good news is that end users are moving to IP and t= heir carriers thus have incentives to do SIP interconnect. I think this wil= l ramp up faster than some expect. 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 Dav= e Crocker Sent: Wednesday, June 19, 2013 2:59 PM To: Rosen, Brian Cc: stir@ietf.org Subject: Re: [stir] Out of band On 6/19/2013 11:41 AM, Rosen, Brian wrote: > Just to be clear, the reason why I want to have the second mechanism soon= er rather than later is that essentially all interconnect between certifica= ted carriers is via SS7. If we don't solve that problem, it won't work. > > The counter argument is that by the time we deploy anything, that won't b= e true. I don't believe that. I don't recall commenting on the timing for specifying this, but rather that it be encapsulated as the gateway-specific mechanism that it is. And that attention be paid to the classic adoption-barrier problem of having the receive side be forced to do a query everytime and blindly and with very small success rates in the early stages of adoption (if not longer.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From richard@shockey.us Wed Jun 19 12:16: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 B627121F9FBC for ; Wed, 19 Jun 2013 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.649 X-Spam-Level: X-Spam-Status: No, score=-100.649 tagged_above=-999 required=5 tests=[AWL=-0.985, 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 AeiEhnExBuRz for ; Wed, 19 Jun 2013 12:16:26 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 5DF3A21F9FB7 for ; Wed, 19 Jun 2013 12:16:24 -0700 (PDT) Received: (qmail 28909 invoked by uid 0); 19 Jun 2013 19:16:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 19 Jun 2013 19:16:21 -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=MUi9QBzPwLu8Xwvl8zfGMak8pX1JVqITFcQbjlK9554=; b=AUENlLvXNUxtl4hQJaEWDS8VbpYaJ4W/6jLsA9gq1lNV3JT6yj/sdgayi2JFasqX330fcVms2eoCOE0tNsm4UryXw3GAeGe00E5R5rHrxm+8aTgPvtTDb81EhpB4SLMe; Received: from [72.66.111.124] (port=53405 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UpNrh-0006Pt-M4 for stir@ietf.org; Wed, 19 Jun 2013 13:16:21 -0600 From: "Richard Shockey" To: Date: Wed, 19 Jun 2013 15:16:19 -0400 Message-ID: <013301ce6d21$7b5b9170$7212b450$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01CE6CFF.F449F170" X-Mailer: Microsoft Outlook 15.0 thread-index: Ac5tITe/sNvINBdoTDiOxv8JbIjMRQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: [stir] Limited time only !! You too can be a amateur telecom lawyer! X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 19:16:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0134_01CE6CFF.F449F170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For those of you who would like to expand this 'conversation' directly the FCC now is your chance! http://www.gpo.gov/fdsys/pkg/FR-2013-06-19/pdf/2013-13703.pdf Comments due July 19. Don't delay, file today ! 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 ------=_NextPart_000_0134_01CE6CFF.F449F170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

For those of = you who would like to expand this ‘conversation’ directly = the FCC now is your chance!

 

ht= tp://www.gpo.gov/fdsys/pkg/FR-2013-06-19/pdf/2013-13703.pdf

 

Comments due July 19. 

 

Don’t = delay,  file today !

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

 

------=_NextPart_000_0134_01CE6CFF.F449F170-- From brian.rosen@neustar.biz Wed Jun 19 12:19: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 D875B21E808A for ; Wed, 19 Jun 2013 12:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 BSRQAfprYTKw for ; Wed, 19 Jun 2013 12:19:51 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D64E021E8053 for ; Wed, 19 Jun 2013 12:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371669482; x=1687024622; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=QQrLfg8PQh 8xz+z6JANzqjT2TnKvaCg8AbJvy8Csimo=; b=pjUYlNgvPaI01649uOejoCUtLd Mq+fgRCg0v1P1HfmBmGiDnwROWS/GhcrwT1cAskzw4BZ9iIoUgR8PCgd5WSg== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19736206; Wed, 19 Jun 2013 15:18:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 15:19:42 -0400 From: "Rosen, Brian" To: "PFAUTZ, PENN L" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9ogiAgAAE4ACAAAOdAIAAAkmA Date: Wed, 19 Jun 2013 19:19:41 +0000 Message-ID: <9E1B8F6E-97F2-4A67-B2A6-2DB31C10687B@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> <51C1FF5A.7020202@dcrocker.net> <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: RYBS3b7wtT1CUIWI74l+4g== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 19:19:55 -0000 SS7 is currently persisting in carrier interconnect because of tariff and o= ther regulatory issues. They may or may not get solved soon. You are more= optimistic than I. If you have SS7 origination, and the identity is spoofed, nothing we are di= scussing will help. If you have SS7 termination, but SIP origination, and at least one "good" S= P in the path, we can fix the problem. If you have SS7 in the middle, and we have at least one "good" SIP SP befor= e the SS7 link, we can fix the problem, but we can't validate all the way t= hrough. Brian On Jun 19, 2013, at 3:11 PM, "PFAUTZ, PENN L" wrote: > I don't want to drag us too far off course but would offer the following = perspective on the timing of SIP interconnection and what we're trying to d= o here: > SS7 interconnection persists where there are SS7 endpoints. Where you hav= e an SS7 originating point/network you are not going to get either inband o= r out of band to work (can't encode for inband; can't post for out of band.= ) Likewise, where you have an SS7 served terminating point/network you won'= t get it either (can't access either validation mechanism; can't show the = result to the called party). > That's the bad news. The good news is that end users are moving to IP and= their carriers thus have incentives to do SIP interconnect. I think this w= ill ramp up faster than some expect. >=20 > Penn Pfautz > AT&T Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of D= ave Crocker > Sent: Wednesday, June 19, 2013 2:59 PM > To: Rosen, Brian > Cc: stir@ietf.org > Subject: Re: [stir] Out of band >=20 > On 6/19/2013 11:41 AM, Rosen, Brian wrote: >> Just to be clear, the reason why I want to have the second mechanism soo= ner rather than later is that essentially all interconnect between certific= ated carriers is via SS7. If we don't solve that problem, it won't work. >>=20 >> The counter argument is that by the time we deploy anything, that won't = be true. I don't believe that. >=20 >=20 > I don't recall commenting on the timing for specifying this, but rather > that it be encapsulated as the gateway-specific mechanism that it is. >=20 > And that attention be paid to the classic adoption-barrier problem of > having the receive side be forced to do a query everytime and blindly > and with very small success rates in the early stages of adoption (if > not longer.) >=20 > 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 timothy.dwight@verizon.com Wed Jun 19 12:40: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 1520E21F9CDB for ; Wed, 19 Jun 2013 12:40:22 -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=[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 DBdgwxAoc6Tl for ; Wed, 19 Jun 2013 12:40:17 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id D295F21F9B85 for ; Wed, 19 Jun 2013 12:40:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 19 Jun 2013 19:40:16 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="500592677" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 19 Jun 2013 19:40:16 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 19 Jun 2013 15:40:15 -0400 To: "Rosen, Brian" , "PFAUTZ, PENN L" Date: Wed, 19 Jun 2013 15:40:14 -0400 Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9ogiAgAAE4ACAAAOdAIAAAkmA///Bz5A= Message-ID: <2B0F677F0B95454297753F58D4A07FA30127CE8D65@FHDP1LUMXC7V31.us.one.verizon.com> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> <51C1FF5A.7020202@dcrocker.net> <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> <9E1B8F6E-97F2-4A67-B2A6-2DB31C10687B@neustar.biz> In-Reply-To: <9E1B8F6E-97F2-4A67-B2A6-2DB31C10687B@neustar.biz> 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" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 19:40:22 -0000 Brian: =20 You said> If you have SS7 origination, and the identity is spoofed, nothing= we are discussing will help. Talk me in off the ledge :-) How does that realization not make this whole= exercise one of chasing the roaches to the other side of the room? tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, June 19, 2013 2:20 PM To: PFAUTZ, PENN L Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Out of band SS7 is currently persisting in carrier interconnect because of tariff and o= ther regulatory issues. They may or may not get solved soon. You are more= optimistic than I. If you have SS7 origination, and the identity is spoofed, nothing we are di= scussing will help. If you have SS7 termination, but SIP origination, and at least one "good" S= P in the path, we can fix the problem. If you have SS7 in the middle, and we have at least one "good" SIP SP befor= e the SS7 link, we can fix the problem, but we can't validate all the way t= hrough. Brian On Jun 19, 2013, at 3:11 PM, "PFAUTZ, PENN L" wrote: > I don't want to drag us too far off course but would offer the following = perspective on the timing of SIP interconnection and what we're trying to d= o here: > SS7 interconnection persists where there are SS7 endpoints. Where you hav= e an SS7 originating point/network you are not going to get either inband o= r out of band to work (can't encode for inband; can't post for out of band.= ) Likewise, where you have an SS7 served terminating point/network you won'= t get it either (can't access either validation mechanism; can't show the = result to the called party). > That's the bad news. The good news is that end users are moving to IP and= their carriers thus have incentives to do SIP interconnect. I think this w= ill ramp up faster than some expect. >=20 > Penn Pfautz > AT&T Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Dave Crocker > Sent: Wednesday, June 19, 2013 2:59 PM > To: Rosen, Brian > Cc: stir@ietf.org > Subject: Re: [stir] Out of band >=20 > On 6/19/2013 11:41 AM, Rosen, Brian wrote: >> Just to be clear, the reason why I want to have the second mechanism soo= ner rather than later is that essentially all interconnect between certific= ated carriers is via SS7. If we don't solve that problem, it won't work. >>=20 >> The counter argument is that by the time we deploy anything, that won't = be true. I don't believe that. >=20 >=20 > I don't recall commenting on the timing for specifying this, but=20 > rather that it be encapsulated as the gateway-specific mechanism that it = is. >=20 > And that attention be paid to the classic adoption-barrier problem of=20 > having the receive side be forced to do a query everytime and blindly=20 > and with very small success rates in the early stages of adoption (if=20 > not longer.) >=20 > 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Wed Jun 19 12:46: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 7CF8421F9C47 for ; Wed, 19 Jun 2013 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 4vmSsPwbsAMR for ; Wed, 19 Jun 2013 12:46:11 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1288421F9C67 for ; Wed, 19 Jun 2013 12:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371671650; x=1687028722; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=aiwopIPvBq Xq1V2tOmXH4X7zOsFuo8zx/ILfE7+TRvM=; b=JKhDtAPINlELjeEnkxlt07dxlq apask2FVhn7BHgSen12E3LgC52R0qg4HSIPvORYC6TcYTiDWCfUC0EtUv83w== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26554471; Wed, 19 Jun 2013 15:54:09 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 15:45:49 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9ogiAgAAE4ACAAAOdAIAAAkmA///Bz5CAAEV9AA== Date: Wed, 19 Jun 2013 19:45:49 +0000 Message-ID: <3A066F78-7FA2-4A1C-80A1-7FCE41188D7C@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> <51C1FF5A.7020202@dcrocker.net> <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> <9E1B8F6E-97F2-4A67-B2A6-2DB31C10687B@neustar.biz> <2B0F677F0B95454297753F58D4A07FA30127CE8D65@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127CE8D65@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: W2oj4Cry5rVXGQ5VwLoZtA== Content-Type: text/plain; charset="us-ascii" Content-ID: <68755DEFC9AB3449B6E809A9FDCED276@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "PFAUTZ, PENN L" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 19:46:15 -0000 Because in most networks, it's actually hard to spoof in the TDM side. Mos= t carriers do a decent job of policing until they get to the SS7 network it= self. What I've seen, and I don't have statistics, is most spoofing is happening = on SIP networks, because it's really easy to do it. Brian On Jun 19, 2013, at 3:40 PM, "Dwight, Timothy M (Tim)" wrote: > Brian: =20 >=20 > You said> If you have SS7 origination, and the identity is spoofed, nothi= ng we are discussing will help. >=20 > Talk me in off the ledge :-) How does that realization not make this who= le exercise one of chasing the roaches to the other side of the room? >=20 > tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Wednesday, June 19, 2013 2:20 PM > To: PFAUTZ, PENN L > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Out of band >=20 > SS7 is currently persisting in carrier interconnect because of tariff and= other regulatory issues. They may or may not get solved soon. You are mo= re optimistic than I. >=20 > If you have SS7 origination, and the identity is spoofed, nothing we are = discussing will help. >=20 > If you have SS7 termination, but SIP origination, and at least one "good"= SP in the path, we can fix the problem. >=20 > If you have SS7 in the middle, and we have at least one "good" SIP SP bef= ore the SS7 link, we can fix the problem, but we can't validate all the way= through. >=20 > Brian >=20 > On Jun 19, 2013, at 3:11 PM, "PFAUTZ, PENN L" wrote: >=20 >> I don't want to drag us too far off course but would offer the following= perspective on the timing of SIP interconnection and what we're trying to = do here: >> SS7 interconnection persists where there are SS7 endpoints. Where you ha= ve an SS7 originating point/network you are not going to get either inband = or out of band to work (can't encode for inband; can't post for out of band= .) Likewise, where you have an SS7 served terminating point/network you won= 't get it either (can't access either validation mechanism; can't show the= result to the called party). >> That's the bad news. The good news is that end users are moving to IP an= d their carriers thus have incentives to do SIP interconnect. I think this = will ramp up faster than some expect. >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dave Crocker >> Sent: Wednesday, June 19, 2013 2:59 PM >> To: Rosen, Brian >> Cc: stir@ietf.org >> Subject: Re: [stir] Out of band >>=20 >> On 6/19/2013 11:41 AM, Rosen, Brian wrote: >>> Just to be clear, the reason why I want to have the second mechanism so= oner rather than later is that essentially all interconnect between certifi= cated carriers is via SS7. If we don't solve that problem, it won't work. >>>=20 >>> The counter argument is that by the time we deploy anything, that won't= be true. I don't believe that. >>=20 >>=20 >> I don't recall commenting on the timing for specifying this, but=20 >> rather that it be encapsulated as the gateway-specific mechanism that it= is. >>=20 >> And that attention be paid to the classic adoption-barrier problem of=20 >> having the receive side be forced to do a query everytime and blindly=20 >> and with very small success rates in the early stages of adoption (if=20 >> not longer.) >>=20 >> 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 >=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 brian.rosen@neustar.biz Wed Jun 19 13: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 A8BA821E80E4 for ; Wed, 19 Jun 2013 13:29:31 -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 IVaH6nGQSSP8 for ; Wed, 19 Jun 2013 13:29:27 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 525F921E80E1 for ; Wed, 19 Jun 2013 13:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371673660; x=1687024622; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Oq9DPhy1k5 D41rh9o9uDYaAKo9i1kEJmEP4dnwknQk8=; b=aYylu/r4YRh+24ByrznU81xdc0 LTmoIcFrpOu0JMdlXKIaLfOEJqSotsLoa16751sXrsqbui2SOx7lHM74jqww== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19739388; Wed, 19 Jun 2013 16:27:39 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 16:29:17 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9wD8A Date: Wed, 19 Jun 2013 20:29:16 +0000 Message-ID: <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> In-Reply-To: <51C1E99A.6080507@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9nYCq3943Ls/xk8GHzIrZw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 20:29:31 -0000 On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: > On 6/19/2013 10:21 AM, Rosen, Brian wrote: >> To be fair, there are some scenarios other than SS7 links where the info= rmation is lost. If we go for an SS7-only solution, we don't cover those c= ases. The mechanisms may be able to be used in other environments. >=20 > What scenarios, specifically? An SBC that mangles the headers that were originally signed >=20 >=20 >> I don't know why you think that we have "vanishingly small success for t= he SS7/SIP queries". >=20 >=20 > This is Transition 101. In the absence of an explicit indicator of suppo= rt, checking for the data is blind; a query must be done every time, whethe= r it will succeed or not. >=20 > Because there is not universal cut-over event, adoption is incremental. = The world starts with zero adoption and tries to move in a positive directi= on. >=20 > Until adoption is very widespread, the likelihood that a query will succe= ed is small because the proportion of adopters doing signing is small. Van= ishingly small. That is exactly the same scenario for the in band mechanism. The problem is that most calls today have at least one SS7 link= From timothy.dwight@verizon.com Wed Jun 19 13:51: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 DDD4321F9C96 for ; Wed, 19 Jun 2013 13:51:23 -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=[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 crH5ih1euONy for ; Wed, 19 Jun 2013 13:51:18 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1522121F89D5 for ; Wed, 19 Jun 2013 13:51:16 -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; 19 Jun 2013 20:51:14 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="492433310" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 19 Jun 2013 20:51:13 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 19 Jun 2013 16:51:13 -0400 To: "Rosen, Brian" Date: Wed, 19 Jun 2013 16:51:12 -0400 Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9ogiAgAAE4ACAAAOdAIAAAkmA///Bz5CAAEV9AP//vVJg Message-ID: <2B0F677F0B95454297753F58D4A07FA30127CE8E48@FHDP1LUMXC7V31.us.one.verizon.com> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> <51C1FF5A.7020202@dcrocker.net> <38726EDA2109264987B45E29E758C4D60495F659@MISOUT7MSGUSR9N.ITServices.sbc.com> <9E1B8F6E-97F2-4A67-B2A6-2DB31C10687B@neustar.biz> <2B0F677F0B95454297753F58D4A07FA30127CE8D65@FHDP1LUMXC7V31.us.one.verizon.com> <3A066F78-7FA2-4A1C-80A1-7FCE41188D7C@neustar.biz> In-Reply-To: <3A066F78-7FA2-4A1C-80A1-7FCE41188D7C@neustar.biz> 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" , "PFAUTZ, PENN L" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 20:51:24 -0000 I agree that it's almost certainly easier and cheaper to spoof your identit= y on VoIP. That doesn't mean it's hard or expensive to do so on a TDM line= though. It just means that one is easy and the other is stupidly easy. I= t is also true, at least in some cases, that carriers police TDM interfaces= . The classic "TDM loophole" for CPN spoofing is the ISDN PRI, which in th= eory supports the option of the calling party number (CPN) being user-provi= ded and unscreened by the carrier. Some carriers (e.g., Verizon) decline t= o support that option due to its potential misuse but I'm sure there are ot= hers that allow it. Anyway, point taken, but still I hope we don't just make VoIP better by mak= ing POTS worse. And I worry about the scenario that "the bugs just move to= the dark side of the room", i.e., that attacks on VoIP endpoints continue = unabated, originated on the PSTN side and using VoIP gateways as "force mul= tipliers" to increase the damage they can cause. By which I refer to the f= act that the information elements that on the PSTN side would have identifi= ed the spoofed CPN as non-trustworthy, don't pass through the VoIP gateway. tim -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Wednesday, June 19, 2013 2:46 PM To: Dwight, Timothy M (Tim) Cc: PFAUTZ, PENN L; stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] Out of band Because in most networks, it's actually hard to spoof in the TDM side. Mos= t carriers do a decent job of policing until they get to the SS7 network it= self. What I've seen, and I don't have statistics, is most spoofing is happening = on SIP networks, because it's really easy to do it. Brian On Jun 19, 2013, at 3:40 PM, "Dwight, Timothy M (Tim)" wrote: > Brian: =20 >=20 > You said> If you have SS7 origination, and the identity is spoofed, nothi= ng we are discussing will help. >=20 > Talk me in off the ledge :-) How does that realization not make this who= le exercise one of chasing the roaches to the other side of the room? >=20 > tim >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Rosen, Brian > Sent: Wednesday, June 19, 2013 2:20 PM > To: PFAUTZ, PENN L > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] Out of band >=20 > SS7 is currently persisting in carrier interconnect because of tariff and= other regulatory issues. They may or may not get solved soon. You are mo= re optimistic than I. >=20 > If you have SS7 origination, and the identity is spoofed, nothing we are = discussing will help. >=20 > If you have SS7 termination, but SIP origination, and at least one "good"= SP in the path, we can fix the problem. >=20 > If you have SS7 in the middle, and we have at least one "good" SIP SP bef= ore the SS7 link, we can fix the problem, but we can't validate all the way= through. >=20 > Brian >=20 > On Jun 19, 2013, at 3:11 PM, "PFAUTZ, PENN L" wrote: >=20 >> I don't want to drag us too far off course but would offer the following= perspective on the timing of SIP interconnection and what we're trying to = do here: >> SS7 interconnection persists where there are SS7 endpoints. Where you ha= ve an SS7 originating point/network you are not going to get either inband = or out of band to work (can't encode for inband; can't post for out of band= .) Likewise, where you have an SS7 served terminating point/network you won= 't get it either (can't access either validation mechanism; can't show the= result to the called party). >> That's the bad news. The good news is that end users are moving to IP an= d their carriers thus have incentives to do SIP interconnect. I think this = will ramp up faster than some expect. >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dave Crocker >> Sent: Wednesday, June 19, 2013 2:59 PM >> To: Rosen, Brian >> Cc: stir@ietf.org >> Subject: Re: [stir] Out of band >>=20 >> On 6/19/2013 11:41 AM, Rosen, Brian wrote: >>> Just to be clear, the reason why I want to have the second mechanism so= oner rather than later is that essentially all interconnect between certifi= cated carriers is via SS7. If we don't solve that problem, it won't work. >>>=20 >>> The counter argument is that by the time we deploy anything, that won't= be true. I don't believe that. >>=20 >>=20 >> I don't recall commenting on the timing for specifying this, but=20 >> rather that it be encapsulated as the gateway-specific mechanism that it= is. >>=20 >> And that attention be paid to the classic adoption-barrier problem of=20 >> having the receive side be forced to do a query everytime and blindly=20 >> and with very small success rates in the early stages of adoption (if=20 >> not longer.) >>=20 >> 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 >=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 dhc@dcrocker.net Wed Jun 19 14:01: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 CFC4F21F9F8D for ; Wed, 19 Jun 2013 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SkMmag0s15jM for ; Wed, 19 Jun 2013 14:01:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5821F9EE0 for ; Wed, 19 Jun 2013 14:01:17 -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 r5JL1CfH027032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 14:01:15 -0700 Message-ID: <51C21C08.7080609@dcrocker.net> Date: Wed, 19 Jun 2013 14:00:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> In-Reply-To: <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> 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, 19 Jun 2013 14:01:16 -0700 (PDT) Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band 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, 19 Jun 2013 21:01:23 -0000 On 6/19/2013 1:29 PM, Rosen, Brian wrote: > > On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: > >> On 6/19/2013 10:21 AM, Rosen, Brian wrote: >>> To be fair, there are some scenarios other than SS7 links where >>> the information is lost. If we go for an SS7-only solution, we >>> don't cover those cases. The mechanisms may be able to be used >>> in other environments. >> >> What scenarios, specifically? > An SBC that mangles the headers that were originally signed So you expect every agent that creates a signature to also stash an entry in the cache and every agent that wants to validate a signature to check "the" cache if there's no signature? If I'm not understanding the usage scenario you envision, please clarify with details. >> Until adoption is very widespread, the likelihood that a query will >> succeed is small because the proportion of adopters doing signing >> is small. Vanishingly small. > > That is exactly the same scenario for the in band mechanism. The > problem is that most calls today have at least one SS7 link No; it's entirely different. The in-band mechanism carries the signal that it is signed. Hence a query is in response to this affirmative indicator. That is, the query is only done in the presence of an explicit indicator that it should be. This is in contrast to the out-of-band query which is done as a blind guess. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Wed Jun 19 14:08: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 72E2C11E80E3 for ; Wed, 19 Jun 2013 14:08:59 -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 GqXGu-3AM4CO for ; Wed, 19 Jun 2013 14:08:55 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 284E121F9E18 for ; Wed, 19 Jun 2013 14:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371676081; x=1687031783; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=o2/65S6Nrq XqNBbou2NR1wEqghvvYY/lLw4D2CFQQWg=; b=o+1hZ61aeJIEULB8Pij4xHeREO /ib/4baCGxkCiuuD4JrWxSrh2XY0pYQCJOtorjW6e7yWPi115PCLNgJBv6OA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21183287; Wed, 19 Jun 2013 17:08:00 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 17:08:44 -0400 From: "Rosen, Brian" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9wD8AgAAI2QCAAAItgA== Date: Wed, 19 Jun 2013 21:08:43 +0000 Message-ID: References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> <51C21C08.7080609@dcrocker.net> In-Reply-To: <51C21C08.7080609@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: KgOxIO5fEpwUVQUVmWxjXQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:08:59 -0000 On Jun 19, 2013, at 5:00 PM, Dave Crocker wrote: > On 6/19/2013 1:29 PM, Rosen, Brian wrote: >>=20 >> On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: >>=20 >>> On 6/19/2013 10:21 AM, Rosen, Brian wrote: >>>> To be fair, there are some scenarios other than SS7 links where >>>> the information is lost. If we go for an SS7-only solution, we >>>> don't cover those cases. The mechanisms may be able to be used >>>> in other environments. >>>=20 >>> What scenarios, specifically? >> An SBC that mangles the headers that were originally signed >=20 >=20 > So you expect every agent that creates a signature to also stash an > entry in the cache and every agent that wants to validate a signature to > check "the" cache if there's no signature? Details vary depending on exactly how this works. In EKR's proposal, yes. = In the SS7 GW idea, it's the SIP->SS7 GW that writes the record and the SS= 7-SIP GW that queries. >=20 > If I'm not understanding the usage scenario you envision, please clarify > with details. >=20 >=20 >>> Until adoption is very widespread, the likelihood that a query will >>> succeed is small because the proportion of adopters doing signing >>> is small. Vanishingly small. >>=20 >> That is exactly the same scenario for the in band mechanism. The >> problem is that most calls today have at least one SS7 link >=20 > No; it's entirely different. >=20 > The in-band mechanism carries the signal that it is signed. Hence a quer= y is in response to this affirmative indicator. That is, the query is only= done in the presence of an explicit indicator that it should be. >=20 > This is in contrast to the out-of-band query which is done as a blind gue= ss. Okay, I misunderstood. Yes, in EKR's you have to do the query on all incom= ing calls that don't have the in-band signature, which won't give you much = useful data until it's well deployed, in mine, the SS7-SIP GW has to query = on all incoming calls with the same small meager success early on. But a query that returns no results is pretty cheap. EKRs is more expensiv= e, because he explicitly tries to make it hard to discover calling patterns= , so the querier has to do work to find good results. In mine, we have more trusted entities and we don't work as hard to avoid t= rolling the database. Doesn't mean we ignore the problem, it's just a bit = easier. From housley@vigilsec.com Wed Jun 19 14:19: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 6654521E80FD for ; Wed, 19 Jun 2013 14:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 tMOjQzSnKiBb for ; Wed, 19 Jun 2013 14:19:25 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2D58921E80EB for ; Wed, 19 Jun 2013 14:19:25 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 709E0F2407C; Wed, 19 Jun 2013 17:19: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 HwnmA3rl3ZRE; Wed, 19 Jun 2013 17:19:18 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DC768F24078; Wed, 19 Jun 2013 17:19:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> Date: Wed, 19 Jun 2013 17:19:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1085) Cc: stir@ietf.org Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:19:31 -0000 Hadriel: > I'm not trying to be difficult - I'm worried because in the BOFs that = I've been to before, whether a problem is solvable in a = useful/deployable fashion is often a criteria for getting a Working = Group created. Or instead during the BOF we get bogged down with lots = of microphone discussion about the viability of solutions, and run out = of time resulting in a request for another BOF before getting a Working = Group. When I think about BOFs, I draw the line differently. I want to know = that the solution space is ready for engineering. That does not mean it = will be easy; hard work and consensus build is okay. However, I want to = know that an interoperability specification can be achieved without = further research. Research problems should be diverted to the IRTF. Russ From dhc@dcrocker.net Wed Jun 19 14:20: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 BCCFC21E810D for ; Wed, 19 Jun 2013 14:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 8i2NlYU29svn for ; Wed, 19 Jun 2013 14:20:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7072621E8101 for ; Wed, 19 Jun 2013 14:20:01 -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 r5JLJu1Y027494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 14:19:59 -0700 Message-ID: <51C2206C.8000603@dcrocker.net> Date: Wed, 19 Jun 2013 14:19:40 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Rosen, Brian" References: <51C1BE9B.4090807@dcrocker.net> <9301A30B-C390-4B99-8F5A-B9F17819575A@neustar.biz> In-Reply-To: <9301A30B-C390-4B99-8F5A-B9F17819575A@neustar.biz> 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, 19 Jun 2013 14:20:00 -0700 (PDT) Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Do we agree on the basics? 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, 19 Jun 2013 21:20:21 -0000 Brian, On 6/19/2013 7:47 AM, Rosen, Brian wrote: >> Some examples of questions that such an approach needs to answer: >> >> 1. What does it do to overall design and operations complexity and >> cost? > Two mechanisms, got to be at least twice the cost I was looking for something a bit more substantive. But as long as you are staying abstract, I'll note that a common clinical assessment about increases to design complexity is that the cost of doubling the mechanisms in a tend toward exponential increases in cost and risk, not linear... >> 2. What is a realistic estimate of the likelihood of major >> benefit; in other words, why should we believe it will help enough >> to warrant the added costs? > > Because we want to solve the problem now, where essentially all > calls go through an SS7 link. Given the query failure rate I cite, it won't solve it. Not for a very, very long time, if ever. And by not solve I mean it won't have an appreciable effect anytime soon. To the extent that you disagree, please cite a detailed scenario that will make a difference and then offer an example of something similar in the last 20 years that was equivalently effective. >> 3. What are the added adoption barriers? > > That depends on the solution. There are several of them, for sure. My intent in asking the question was to look for substantive responses. The questions are merely classic ones of the type used to analyze design and use choices, so that the process isn't merely a random walk down a lane of personal preferences and intuition. Most schemes fail. Considering concrete adoption barriers and value propositions carefully beforehand tends to reduce the likelihood of failure. >> 4. What are the early-stage costs, such as when almost no one has >> it implemented? >> >> For example, the stated use is when the call request arrives >> without the signature information; this will look exactly the same >> as a call from a system that did not add the signature. Initially >> the latter will be far, far more common than the former. Almost >> no one will be signing. Hence, the querying agent is going to be >> making unsuccessful alternative checks essentially every time. >> Failure rates at that level discourage adoption. > For one thing the same is true for the in band mechanism. > > Sure, there is a cost for the out of band mechanism. > > It's mostly fixed cost, but there are always transaction volume > related costs. By saying "early-stage" I meant to focus not on the simple mechanics but on the operational concerns present when there are few adopters. When an ops person is asked to implement something new, their obvious question is about the benefit that will be obtained. Now. Tell them the benefit will be later and they will say that's when they'll deploy. > Actually, some of us are worried that the problem of the out of band > mechanism is that by the time we've deployed it, and sunk most of > the cost, the problem goes away. That sounds like an expectation of very fast deployment of the core mechanism. For telcos? So, most of the world's telcos have already promised to deploy the technology as quickly as possible? > Others think that there will always be some barriers and the out of > band mechanism has value for a very long time. Which better matches typical Internet transition experiences. > The costs are mostly the database itself, and the implementation in > wherever it is done. In EKR's idea, it's at the ends (device or > services). In the alternate idea I just described, it's in the > gateways (or near them, a B2BUA could do it). In terms of basic design, among various other concerns, I was struck by the scheme's apparent reliance on a centralized mechanism. For the entire Internet. -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Wed Jun 19 14:24: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 0A53611E80DF for ; Wed, 19 Jun 2013 14:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 UejN1OqivYSO for ; Wed, 19 Jun 2013 14:24:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 85FAC21E80AC for ; Wed, 19 Jun 2013 14:24: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 r5JLOBTC027592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 14:24:14 -0700 Message-ID: <51C2216A.4020402@dcrocker.net> Date: Wed, 19 Jun 2013 14:23:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Russ Housley References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 19 Jun 2013 14:24:14 -0700 (PDT) Cc: stir@ietf.org, Hadriel Kaplan Subject: Re: [stir] Do we agree on the basics? 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, 19 Jun 2013 21:24:27 -0000 On 6/19/2013 2:19 PM, Russ Housley wrote: > Hadriel: > >> I'm not trying to be difficult - I'm worried because in the BOFs >> that I've been to before, whether a problem is solvable in a >> useful/deployable fashion is often a criteria for getting a Working >> Group created. Or instead during the BOF we get bogged down with >> lots of microphone discussion about the viability of solutions, and >> run out of time resulting in a request for another BOF before >> getting a Working Group. > > When I think about BOFs, I draw the line differently. I want to know > that the solution space is ready for engineering. That does not mean > it will be easy; hard work and consensus build is okay. However, I > want to know that an interoperability specification can be achieved > without further research. > > Research problems should be diverted to the IRTF. Russ, Sorry, but now I'm even more confused than usual. Given your note classes your perspective as being in opposition to Hadriels, please explain how "ready for engineering" means something different from "solvable in a useful/deployable fashion." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yiu_lee@cable.comcast.com Wed Jun 19 14:30: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 C031C21E80AC for ; Wed, 19 Jun 2013 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 fI4noy21NaOH for ; Wed, 19 Jun 2013 14:30:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4E21E80B2 for ; Wed, 19 Jun 2013 14:30:35 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78243950; Wed, 19 Jun 2013 15:29:57 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 19 Jun 2013 17:30:31 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 17:30:31 -0400 From: "Lee, Yiu" To: "stir@ietf.org" Thread-Topic: [stir] current draft charter - ENUM and databases Thread-Index: AQHObTQ5XmPLrMwRWEiVEqWBKKhJyg== Date: Wed, 19 Jun 2013 21:30:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.247] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3454507829_25597" MIME-Version: 1.0 Subject: Re: [stir] current draft charter - ENUM and databases X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:30:43 -0000 --B_3454507829_25597 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I pretty much agree what you said. The Identity-Info field is very flexible. I guess we need to agree with the problem we tried to solve first in stir. My gut feeling is we may be able to use rfc4474 plus some minor twists to get what we want. On 6/19/13 2:18 PM, "Peterson, Jon" wrote: > >I think this list has gotten bogged down in the question of how to >download credentials at the verification service. I sense this is >motivated by a feeling that we are going to have a beauty contest and pick >one way to download credentials, and everyone would like it to be their >favorite way. > >I don't really look at the STIR problem that way, though. I don't really >care, at the end of the day, how a verification service downloads >credentials. I don't think we even need to arrival a single way of doing >it. The Identity-Info header of RFC4474 gives verification services a hint >of where they could acquire credentials. Nothing about RFC4474 assumes >though that the verification service doesn't already have a public key for >the auth service, or that the verification service doesn't have its own >means of looking up credentials in a store, say (see Step 1 of Section 6 >of RFC4474). Dereferencing the Identity-Info is not in that strict sense >required. > >Even when there verification service does dereference the URI in >Identity-Info to get a credential, RFC4474 leaves the door pretty wide >open for what protocols can be used: it does specify HTTP as MTI, but this >is not exclusive. We discussed using SIP itself (with a fetch SUB), CID >for multipart MIME and several other options. I can even imagine using a >DNS URI for this, especially for a DANE or DANE-like case where you want >to tip off the verifier that the public key can be found in the DNS. >Again, the presence of a DNS URI in Identity-Info would just be a hint, a >"in case you didn't know, my public key is in a DANE record." Maybe some >verification services wouldn't need that hint as they always check the DNS >for a public key. > >So you could argue even that at an over-the-wire level, we wouldn't even >need to change Identity-Info to support using the DNS as a way to access >credentials. What would need to change, of course, is the logic used by >auth/verification services to handle telephone numbers, and for DANE-like >cases, to check reference integrity. This, I think, is where the actual >STIR work should lie. I don't think we should try to legislate a one true >way that services must make credentials available. We should introduce >flexibility here, even if it means perhaps having two MTIs for >Identity-Info URI schemes instead of one. But we shouldn't get caught up >on what protocol you use to fetch credentials. > >Jon Peterson >Neustar, Inc. > >On 6/19/13 10:23 AM, "Lee, Yiu" wrote: > >>Can we get the dnskey record and verify it by the ds record and forget >>the >>whole CA thing? >> >>On 6/19/13 1:12 PM, "Hadriel Kaplan" wrote: >> >>>We have can't just look up the DNS domain key of 'foo.com' to get the >>>certificate > --B_3454507829_25597 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLNK cmT0Ua2gwDZLoUWFCeFDCJZ1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDYxOTIxMzAyOFowDQYJKoZIhvcNAQEBBQAEggEARX6RjWIOQ8TRuNlmtEdx JYYUz9NDsyZD1Nh+Gsma30IeqAoWjLF6+lhL01qMgdWMI3JLMw/hGGyeBu1DihW65CAFTOyJ WsUPD99OSMr0KQsW2vOO+ntN2dcAHTWQoy25GphXn0N5Pot0SueFykW858v1FKLTJ/JUUiAv nsj2j27kue0ztCMcGr3TSD8U4T2Soov9k29fwFu0Am95fZ5Sx18wJZDAB7hXUYu8OMzeYYo3 g6RdvBCWn9XSTZTvL6QN/QJntxLpZgwZxjP1mGr65bhTi6UryVL1qk92bXZ71DMzgH55tc6E l311RTqPkRoRiHBTMeHhTnVJR7Py+IaolQ== --B_3454507829_25597-- From hadriel.kaplan@oracle.com Wed Jun 19 14:36: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 3A92621F9F7E for ; Wed, 19 Jun 2013 14:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_24=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 1HVoz72gGlRI for ; Wed, 19 Jun 2013 14:36:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A921F21F9F3B for ; Wed, 19 Jun 2013 14:36:30 -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 r5JLU7if002646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 21:30:08 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 r5JLaOO7012027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 21:36:25 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JLaOk1012024; Wed, 19 Jun 2013 21:36:24 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 14:36:24 -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: <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> Date: Wed, 19 Jun 2013 17:36:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:36:37 -0000 On Jun 19, 2013, at 4:29 PM, "Rosen, Brian" = wrote: >=20 > On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: >=20 >> On 6/19/2013 10:21 AM, Rosen, Brian wrote: >>> To be fair, there are some scenarios other than SS7 links where the = information is lost. If we go for an SS7-only solution, we don't cover = those cases. The mechanisms may be able to be used in other = environments. >>=20 >> What scenarios, specifically? > An SBC that mangles the headers that were originally signed Ugh, this is like deja vu all over again. The reasons why an SBC = *should* "mangle" the headers has been explained numerous times. The = reasons why most users should actually *want* them to be "mangled" by = SBCs has been explained numerous times. And the reasons why those = headers aren't *necessary* to sign have also been explained numerous = times. Some of the info the SBC "mangles" is changed to actually make the call = *work*, or because the owners of them *want* those fields to be changed. = Sending them un-changed in an out-of-band channel won't mean anything = to the receiver of the call: it won't provide assurance of anything, and = can't be used directly. For example, 4474 signs the SDP body. One of the purported reasons it = does this is to protect the IP:port info of the media because it = identifies the caller's media. Let's ignore the fact that an IP address = is not a user identity, and that RTP over UDP traffic is trivial to = spoof, and that it doesn't actually identify the end host most of the = time due to NATs/Firewalls anyway... let's instead just assume this = IP:port SDP info reaches the far-end destination of the call in this = out-of-band channel. What would this IP Address actually mean?? It's = not usable, because it's highly likely to be a private IP Address in = someone else's private network. And its not where the media will = actually come from or go to, because the media needs to go to the SBC = instead. So what good does it do you to get it?? Or another example is 4474 signing the Contact. The claimed reason for = this was to prevent a MitM from changing the Contact such that it would = be able to intercept future messages. Again, let's ignore the fact it = doesn't actually prevent the attack threat, because a MitM can insert = Record-Routes all day long to achieve the same goal... let's just assume = the Contact reaches the far-end in an out-of-band channel. What would = it mean to you? What would you use it for? And why should I let you = learn my Contact URI, which typically contains my host IP Address? SBCs = change it in order to (1) make call scenarios work right, because = certain call scenarios cannot work without changing the contact, and = more importantly (2) to protect each party by hiding their IP = Addresses;, because if someone calls my house, I don't expect that = someone to learn my IP Address just because my phone rings or my = answering machine answers; or vice-versa, if I call someone else I don't = expect them to learn my IP Address just because I called them. And some of the info the SBC "mangles" isn't actually necessary for an = identity verification mechanism to work. For example the Call-ID. It's = signed by 4474 as a means of preventing replay. But we know it didn't = have to be, that a different field could have been created for that = purpose instead. It was simply *convenient* to use it for 4474. Let's face it: we screwed up with 4474. We knew the problems with it, = we had the debates about it, and we ignored the problems in the hope = that the World would change to accommodate the IETF's vision. It = didn't. -hadriel From housley@vigilsec.com Wed Jun 19 14: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 6AAB321E80B8 for ; Wed, 19 Jun 2013 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 dZ38PeyZcvRm for ; Wed, 19 Jun 2013 14:41:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1567D21F9C51 for ; Wed, 19 Jun 2013 14:41:32 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C52CAF2407C; Wed, 19 Jun 2013 17:41:41 -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 LfYVjhTbmcpz; Wed, 19 Jun 2013 17:40:34 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2316FF24078; Wed, 19 Jun 2013 17:41:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51C2216A.4020402@dcrocker.net> Date: Wed, 19 Jun 2013 17:41:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <51C2216A.4020402@dcrocker.net> To: Hadriel Kaplan , Dave Crocker X-Mailer: Apple Mail (2.1085) Cc: stir@ietf.org Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:41:38 -0000 Dave: >>> I'm not trying to be difficult - I'm worried because in the BOFs >>> that I've been to before, whether a problem is solvable in a >>> useful/deployable fashion is often a criteria for getting a Working >>> Group created. Or instead during the BOF we get bogged down with >>> lots of microphone discussion about the viability of solutions, and >>> run out of time resulting in a request for another BOF before >>> getting a Working Group. >>=20 >> When I think about BOFs, I draw the line differently. I want to know >> that the solution space is ready for engineering. That does not mean >> it will be easy; hard work and consensus build is okay. However, I >> want to know that an interoperability specification can be achieved >> without further research. >>=20 >> Research problems should be diverted to the IRTF. >=20 > ,Sorry, but now I'm even more confused than usual. >=20 > Given your note classes your perspective as being in opposition to = Hadriels, please explain how "ready for engineering" means something = different from "solvable in a useful/deployable fashion." I'll try to be more clear. Hadriel says that he is worried about spending BOF time on the viability = of different solutions. He fears that will take so much time in the = meeting that we will not be able to get to the work needed to charter a = Working Group. I agree. BOF time should be spent making sure that there is a solution = space that will lead to an interoperability specification. That is, = make sure the work being considered is engineering, not research. Once = chartered, a Working Group can consider many different approaches, = perhaps even specify a hybrid. The point is that once the BOF is convinced that the solution is in the = engineering space, no further time in the BOF session need be spent = discussing the various different alternatives. Hadriel correctly call = that "bogged down." Russ From dhc@dcrocker.net Wed Jun 19 14:48: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 A786621E80B8 for ; Wed, 19 Jun 2013 14:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 UrHlYZ2XZfSl for ; Wed, 19 Jun 2013 14:48:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70621E80FC for ; Wed, 19 Jun 2013 14:48:06 -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 r5JLm2cJ028058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 14:48:05 -0700 Message-ID: <51C22702.4060801@dcrocker.net> Date: Wed, 19 Jun 2013 14:47:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Russ Housley References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <51C2216A.4020402@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]); Wed, 19 Jun 2013 14:48:06 -0700 (PDT) Cc: stir@ietf.org Subject: Re: [stir] Do we agree on the basics? 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, 19 Jun 2013 21:48:12 -0000 On 6/19/2013 2:41 PM, Russ Housley wrote: > Hadriel says that he is worried about spending BOF time on the viability of different solutions. He fears that will take so much time in the meeting that we will not be able to get to the work needed to charter a Working Group. > > I agree. BOF time should be spent making sure that there is a solution space that will lead to an interoperability specification. That is, make sure the work being considered is engineering, not research. Once chartered, a Working Group can consider many different approaches, perhaps even specify a hybrid. > > The point is that once the BOF is convinced that the solution is in the engineering space, no further time in the BOF session need be spent discussing the various different alternatives. Hadriel correctly call that "bogged down." Ahh. Yes, thanks. I'll take that as your agreeing with the danger, but offering a view of how to limit it. Simplistically I think means criticism of proposals need to assert and justify a claim that they won't work, rather than that one is better than another.[*] Sure hope the bof chairs are good at enforcing that discipline... Sounds like fun. d/ [*] of course, there are plenty of ratholes to go down with even this more constrained debate scope, but still... -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Wed Jun 19 14:54: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 B742621F9E4A for ; Wed, 19 Jun 2013 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_24=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 O5EBhywYiUbR for ; Wed, 19 Jun 2013 14:54:38 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7686821F9F13 for ; Wed, 19 Jun 2013 14:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371678771; x=1687024622; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Xo39s6yn+E 0H/9qMlNjEgl+G5K97DKpMAjDpudu7KbY=; b=f+HLUU0zWROXWTmpydxixWmuHa w6dApy1fXV2bDO7HbYcQ1hzpo7b0rn0JZSmPYVu7j5Q6j9pgV8AFP+xoLShw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19742695; Wed, 19 Jun 2013 17:52:50 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 17:54:31 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , "Rosen, Brian" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIZ5WTLe3h5QUi+OSn3enNelJk9wD8AgAASwAD//4+3gA== Date: Wed, 19 Jun 2013 21:54:31 +0000 Message-ID: In-Reply-To: <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: muoWXwVaTZIRwoAl1qPV1A== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 21:54:42 -0000 I don't think anyone here is particularly interested in retreading this debate; I think we all agree STIR would be adopting a signature algorithm that differs from RFC4474 in a way that is intended to make it possible for it to survive SBCs. I think how I'd cast what I think Brian was getting it was more like this: there are going to be forms of B2BUAs, like PSTN gateways, maybe gateways associated with other standard or proprietary protocols, whatever, that are going to effectively remove the Identity headers no matter how friendly we make them. That's just a fact of life. We want to try to arrange things so that it won't happen as a part of ordinary SBC operation, but again, I think the problem space of robocalling involves all kinds of use cases where SIP is only used over part of the call path, or potentially even none of it. The secure-origins-ps draft lists many scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. If we had some capability to let the originating and terminating side verify, more securely than what would get from hop-by-hop trust, that a call setup attempt from the originating number is in place, a capability that could work around these kinds of extremely adverse B2BUA conditions, it would help the impersonation problem. Those of us who spun our gears on the VIPR problem for a while know that this isn't trivial, but VIPR is at least one (implemented and even deployed, though not widely used) example of how Internet endpoints could discover one another as endpoints of a call and use that out-of-band connection to enhance identity and security. Clearly the knobs were not set in an ideal position for VIPR, so what we want to explore is ways of addressing the problem space that will be more likely to succeed. In part, that will extracting components out of the very vertical and monolithic VIPR proposal: the CDS straw men are examples of what one of those components would look like (roughly taking the place of the VIPR DHT). I think many of us feel that the smartphone revolution has created some new opportunities in this space that weren't around when we first started working on all this. The way the charter is structured, this out-of-band deliverable is placed after the we get done with the Identity signature revisitation, so I don't think this would be the first order of business. I do however think that we should define how that system will interface with Identity, and how the credentials of the systems are related (or different), and that it belongs in the scope of STIR. Jon Peterson Neustar, Inc. On 6/19/13 2:36 PM, "Hadriel Kaplan" wrote: > >On Jun 19, 2013, at 4:29 PM, "Rosen, Brian" >wrote: > >>=20 >> On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: >>=20 >>> On 6/19/2013 10:21 AM, Rosen, Brian wrote: >>>> To be fair, there are some scenarios other than SS7 links where the >>>>information is lost. If we go for an SS7-only solution, we don't >>>>cover those cases. The mechanisms may be able to be used in other >>>>environments. >>>=20 >>> What scenarios, specifically? >> An SBC that mangles the headers that were originally signed > > >Ugh, this is like deja vu all over again. The reasons why an SBC >*should* "mangle" the headers has been explained numerous times. The >reasons why most users should actually *want* them to be "mangled" by >SBCs has been explained numerous times. And the reasons why those >headers aren't *necessary* to sign have also been explained numerous >times. > >Some of the info the SBC "mangles" is changed to actually make the call >*work*, or because the owners of them *want* those fields to be changed. >Sending them un-changed in an out-of-band channel won't mean anything to >the receiver of the call: it won't provide assurance of anything, and >can't be used directly. > >For example, 4474 signs the SDP body. One of the purported reasons it >does this is to protect the IP:port info of the media because it >identifies the caller's media. Let's ignore the fact that an IP address >is not a user identity, and that RTP over UDP traffic is trivial to >spoof, and that it doesn't actually identify the end host most of the >time due to NATs/Firewalls anyway... let's instead just assume this >IP:port SDP info reaches the far-end destination of the call in this >out-of-band channel. What would this IP Address actually mean?? It's >not usable, because it's highly likely to be a private IP Address in >someone else's private network. And its not where the media will >actually come from or go to, because the media needs to go to the SBC >instead. So what good does it do you to get it?? > >Or another example is 4474 signing the Contact. The claimed reason for >this was to prevent a MitM from changing the Contact such that it would >be able to intercept future messages. Again, let's ignore the fact it >doesn't actually prevent the attack threat, because a MitM can insert >Record-Routes all day long to achieve the same goal... let's just assume >the Contact reaches the far-end in an out-of-band channel. What would it >mean to you? What would you use it for? And why should I let you learn >my Contact URI, which typically contains my host IP Address? SBCs change >it in order to (1) make call scenarios work right, because certain call >scenarios cannot work without changing the contact, and more importantly >(2) to protect each party by hiding their IP Addresses;, because if >someone calls my house, I don't expect that someone to learn my IP >Address just because my phone rings or my answering machine answers; or >vice-versa, if I call someone else I don't expect them to l > earn my IP Address just because I called them. > >And some of the info the SBC "mangles" isn't actually necessary for an >identity verification mechanism to work. For example the Call-ID. It's >signed by 4474 as a means of preventing replay. But we know it didn't >have to be, that a different field could have been created for that >purpose instead. It was simply *convenient* to use it for 4474. > >Let's face it: we screwed up with 4474. We knew the problems with it, we >had the debates about it, and we ignored the problems in the hope that >the World would change to accommodate the IETF's vision. It didn't. > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Wed Jun 19 15:19: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 B699A21F9EFE for ; Wed, 19 Jun 2013 15:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 MoIyqqdrdaI0 for ; Wed, 19 Jun 2013 15:19:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B338121F9EE7 for ; Wed, 19 Jun 2013 15:19:43 -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 r5JMJP4q028533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 15:19:28 -0700 Message-ID: <51C22E5C.900@dcrocker.net> Date: Wed, 19 Jun 2013 15:19:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 19 Jun 2013 15:19:28 -0700 (PDT) Cc: "Rosen, Brian" , Hadriel Kaplan , "dcrocker@bbiw.net" , "stir@ietf.org" Subject: Re: [stir] Out of band 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, 19 Jun 2013 22:19:49 -0000 Jon, On 6/19/2013 2:54 PM, Peterson, Jon wrote: > > I don't think anyone here is particularly interested in retreading this > debate; I think we all agree STIR would be adopting a signature algorithm > that differs from RFC4474 RFC 4474's discussion of signature algorithm is quite limited, with a some quick referencs e to "sha1WithRSAEncryption as described in RFC 3370". And I don't think I've seen any serious concern about signature algorithms in this thread. Rather, discussion has been about basic approaches to system design. To the extent that a design includes signing, the algorithmic details aren't (and aren't likely to be) controversial. In contrast, the system design is. > in a way that is intended to make it possible > for it to survive SBCs. Perhaps I've missed it, but I don't think there are any proposals for survival, but rather one scheme that proposes something that invokes the "routing around" mantra popular on the net, to allow re-asserting the signature. And it seems to be offered as an addition to an RFC 4474 base, rather than as an alternative to (differing from) it. That is, the proposal appears to be to use 4474 and then add a mechanism that attempts to "work around" destruction of the signature. Please correct me if I'm wrong about these basic points. Then the question for this added mechanism is whether it is at all viable in real-world scenarios and scale. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Wed Jun 19 15:31: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 CE94221F9EA3 for ; Wed, 19 Jun 2013 15:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 YndwwaH0O9e1 for ; Wed, 19 Jun 2013 15:31:18 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id BBCAA21F9E18 for ; Wed, 19 Jun 2013 15:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371680971; x=1687024622; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=qnoAM8TPA1 ov0x6cJEUJ1ZwfRi6omS+pBczg61jMRM0=; b=JV5pKBe2j74WsDdHJjOZHpfiTW SD+AZnmaTyv/o/f6Z3PwKhI//1kisFL8REQBzRNTNe39hGR60DI2sR4HfzQw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19743674; Wed, 19 Jun 2013 18:29:30 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 18:31:08 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out of band Thread-Index: AQHObRIZ5WTLe3h5QUi+OSn3enNelJk9wD8AgAASwAD//4+3gIAAfDwA//+N/oA= Date: Wed, 19 Jun 2013 22:31:07 +0000 Message-ID: In-Reply-To: <51C22E5C.900@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: EdjgsiKM4DvTDcpRDnHd2g== Content-Type: text/plain; charset="us-ascii" Content-ID: <9B7CEF365492CD4EAAEF11DF3918B66A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , Hadriel Kaplan , "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 19 Jun 2013 22:31:22 -0000 On 6/19/13 3:19 PM, "Dave Crocker" wrote: >Jon, > >On 6/19/2013 2:54 PM, Peterson, Jon wrote: >> >> I don't think anyone here is particularly interested in retreading this >> debate; I think we all agree STIR would be adopting a signature >>algorithm >> that differs from RFC4474 > >RFC 4474's discussion of signature algorithm is quite limited, with a >some quick referencs e to "sha1WithRSAEncryption as described in RFC >3370". And I don't think I've seen any serious concern about signature >algorithms in this thread. There will be some things to discuss there, I'm pretty sure. >Rather, discussion has been about basic approaches to system design. To >the extent that a design includes signing, the algorithmic details >aren't (and aren't likely to be) controversial. > >In contrast, the system design is. I think there's room for controversy about both. I'm not sure you and I entirely agree about what is the scope of the IETF when it comes to "system design," but I definitely agree that in so far as the system design impacts the design of the protocols we'd specify in the IETF, we need to understand its characteristics. >> in a way that is intended to make it possible >> for it to survive SBCs. > >Perhaps I've missed it, but I don't think there are any proposals for >survival, but rather one scheme that proposes something that invokes the >"routing around" mantra popular on the net, to allow re-asserting the >signature. Well, the phrase you excerpted here was talking about the in-band work, not the out-of-band work. The in-band work is indeed intended to create a signature that would survival SBCs. >And it seems to be offered as an addition to an RFC 4474 base, rather >than as an alternative to (differing from) it. That is, the proposal >appears to be to use 4474 and then add a mechanism that attempts to >"work around" destruction of the signature. Correct. Broadly, the creator of a SIP request isn't going to be able to tell whether or not there will be SIP end-to-end, and thus whether the 4474 signature will survive end-to-end. So yes, 4474 surviving is the sunny day outcome. To plan for rainy days, both mechanisms could be invoked roughly as you describe. >Please correct me if I'm wrong about these basic points. > >Then the question for this added mechanism is whether it is at all >viable in real-world scenarios and scale. Sure. Jon Peterson Neustar, Inc. >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From hadriel.kaplan@oracle.com Wed Jun 19 17:51: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 8051D21F9DF0 for ; Wed, 19 Jun 2013 17:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 MTs97neX53IU for ; Wed, 19 Jun 2013 17:51:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7A121F9D2D for ; Wed, 19 Jun 2013 17:51:24 -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 r5K0pIEL017565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 00:51:19 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 r5K0pHjk017624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 00:51:18 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 r5K0pHFx004796; Thu, 20 Jun 2013 00:51:17 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 17:51:17 -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: <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> Date: Wed, 19 Jun 2013 20:51:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 00:51:31 -0000 On Jun 19, 2013, at 2:41 PM, "Rosen, Brian" = wrote: > Just to be clear, the reason why I want to have the second mechanism = sooner rather than later is that essentially all interconnect between = certificated carriers is via SS7. If we don't solve that problem, it = won't work. > The counter argument is that by the time we deploy anything, that = won't be true. I don't believe that. To be fair to your view, I don't think anyone really believes SS7 will = be _completely_ gone in the sense of universal, no-exceptions, complete = disappearance of SS7. There'll always be some usage for many decades to = come. Even the hand-cranked human-operator-switched phones existed = somewhere in the USA into the 1980s (someplace in Maine I think). And = someone probably still uses Token Ring, 5.25 inch floppies, and even = Fore Systems ASX-100 switches. ;) I agree there'll be quite a bit of SS7, including between carriers, for = the next 10, 20, or even 30 years from now. That'll especially be true = in specific countries and regions of the World, which probably don't = need to be listed here. But for the group of carriers/countries/enterprises that we care about - = for the group that would even do anything new, for the group who even = have IP on both "ends" to consider an IP-based out-of-band mechanism = between each other, for the group who see the problem coming and are = willing to do something to prevent it - for *that* group, I think SS7 = interconnect is going away pretty darn fast. And some of them already = have SIP interconnect. (My previous employer sold thousands of SBCs just = for interconnecting carriers, so it must happen somewhere!) I think it's very hard to try to convince the "modern" carriers to spend = even more money in order to support an ever-shrinking group of "legacy" = carriers. The business motivation here is backwards. Having said that, I do also think we can at least specify how a STIR = in-band model could work through SS7, for example in a UUI. It might = even be usable if the "SS7" portion is very short and well-managed. We = could never guarantee it would work, but it might in some specific cases = of SS7 in-the-middle. For the real legacy SS7 carriers, though... most of those won't be = applicable to either STIR or an out-of-band mechanism, because they use = SS7 in their whole TDM network, and obviously there's not a lot of new = development going on in SS7 products. These carriers don't offer SIP = trunks, or SIP access of any kind. Just POTS and PRIs. The theory = espoused on this list has been: such networks generate relatively good = caller-IDs. So even for an out-of-band approach, I don't see them = getting certs, or using them, or verifying anything. -hadriel From dhc@dcrocker.net Wed Jun 19 18:10: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 A57C021F9F39 for ; Wed, 19 Jun 2013 18:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 bhFygWc1IZFU for ; Wed, 19 Jun 2013 18:10:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A393F21F9EF0 for ; Wed, 19 Jun 2013 18:10:26 -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 r5K1ANOZ031890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 18:10:26 -0700 Message-ID: <51C2566D.8050005@dcrocker.net> Date: Wed, 19 Jun 2013 18:10:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 19 Jun 2013 18:10:26 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out of band 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, 20 Jun 2013 01:10:31 -0000 On 6/19/2013 3:31 PM, Peterson, Jon wrote: > On 6/19/13 3:19 PM, "Dave Crocker" wrote: >> Rather, discussion has been about basic approaches to system design. To >> the extent that a design includes signing, the algorithmic details >> aren't (and aren't likely to be) controversial. >> >> In contrast, the system design is. > > I think there's room for controversy about both. There's room for controversy about anything. Or perhaps we could debate /that/... Discussing and refining is defferent from debating what is controversial. My point was about what's already established as controversial vs. what's likely. Debating the details of a signing algorithm is not likely. Debating approaches to the overall design of the authorization service already is controversial and it's likely to stay that way for awhile. > I'm not sure you and I > entirely agree about what is the scope of the IETF when it comes to > "system design," That part of your statement is surprising enough to me that I have no idea what you mean by system design. As for me, I mean it in the usual way it's used in the IETF and elsewhere to refer to the definition and arrangement of components and their interactions to achieving any complete service. In this case, that means the end-to-end components and their interactions, needed to establish authorization for a TN appearing in the From field. In the IETF, a system is often characterized within an architecture or service description document. Protocols are the rules of interaction between components. >>> in a way that is intended to make it possible >>> for it to survive SBCs. >> >> Perhaps I've missed it, but I don't think there are any proposals for >> survival, but rather one scheme that proposes something that invokes the >> "routing around" mantra popular on the net, to allow re-asserting the >> signature. > > Well, the phrase you excerpted here was talking about the in-band work, > not the out-of-band work. The in-band work is indeed intended to create a > signature that would survival SBCs. Brian just got done citing SBCs as an example of needing the out of band mechanism. >> And it seems to be offered as an addition to an RFC 4474 base, rather >> than as an alternative to (differing from) it. That is, the proposal >> appears to be to use 4474 and then add a mechanism that attempts to >> "work around" destruction of the signature. > > Correct. Broadly, the creator of a SIP request isn't going to be able to > tell whether or not there will be SIP end-to-end, and thus whether the > 4474 signature will survive end-to-end. So yes, 4474 surviving is the > sunny day outcome. To plan for rainy days, both mechanisms could be > invoked roughly as you describe. So the design and operational requirement you've just defined is two entirely redundant mechanisms to be employed for every call. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hgs@cs.columbia.edu Wed Jun 19 18:17: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 1F14021F9EFE for ; Wed, 19 Jun 2013 18:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 qkGQXaDwpPFq for ; Wed, 19 Jun 2013 18:17:11 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id A970E21F9F0A for ; Wed, 19 Jun 2013 18:17:09 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5K1GvAD012536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Jun 2013 21:17:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Wed, 19 Jun 2013 21:16:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67884B84-F4CB-44BE-8C06-56569B4107B7@cs.columbia.edu> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <51BCEF16-1DE2-4B91-AA89-D23DB8579F71@neustar.biz> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "Rosen, Brian" , "" , "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 01:17:25 -0000 I don't see any harm in providing guidance on how to carry things = through SS7 clouds. This isn't likely to be all that complicated (we = already have general carry-SIP-stuff-in-SS7 documents), and as long as = we don't depend on it, the worst-case outcome is another RFC that nobody = implements. My suspicion is that the most common model will be that you've reached = mostly "good guys" once you enter the first SS7 link. As long as that = first SS7 gateway validates the SIP call, you're back to roughly the = pre-VoIP status quo, i.e., mostly reliable caller ID.=20 Henning On Jun 19, 2013, at 8:51 PM, Hadriel Kaplan wrote: >=20 > On Jun 19, 2013, at 2:41 PM, "Rosen, Brian" = wrote: >=20 >> Just to be clear, the reason why I want to have the second mechanism = sooner rather than later is that essentially all interconnect between = certificated carriers is via SS7. If we don't solve that problem, it = won't work. >> The counter argument is that by the time we deploy anything, that = won't be true. I don't believe that. >=20 > To be fair to your view, I don't think anyone really believes SS7 will = be _completely_ gone in the sense of universal, no-exceptions, complete = disappearance of SS7. There'll always be some usage for many decades to = come. Even the hand-cranked human-operator-switched phones existed = somewhere in the USA into the 1980s (someplace in Maine I think). And = someone probably still uses Token Ring, 5.25 inch floppies, and even = Fore Systems ASX-100 switches. ;) >=20 > I agree there'll be quite a bit of SS7, including between carriers, = for the next 10, 20, or even 30 years from now. That'll especially be = true in specific countries and regions of the World, which probably = don't need to be listed here. >=20 > But for the group of carriers/countries/enterprises that we care about = - for the group that would even do anything new, for the group who even = have IP on both "ends" to consider an IP-based out-of-band mechanism = between each other, for the group who see the problem coming and are = willing to do something to prevent it - for *that* group, I think SS7 = interconnect is going away pretty darn fast. And some of them already = have SIP interconnect. (My previous employer sold thousands of SBCs just = for interconnecting carriers, so it must happen somewhere!) >=20 > I think it's very hard to try to convince the "modern" carriers to = spend even more money in order to support an ever-shrinking group of = "legacy" carriers. The business motivation here is backwards. >=20 > Having said that, I do also think we can at least specify how a STIR = in-band model could work through SS7, for example in a UUI. It might = even be usable if the "SS7" portion is very short and well-managed. We = could never guarantee it would work, but it might in some specific cases = of SS7 in-the-middle. >=20 > For the real legacy SS7 carriers, though... most of those won't be = applicable to either STIR or an out-of-band mechanism, because they use = SS7 in their whole TDM network, and obviously there's not a lot of new = development going on in SS7 products. These carriers don't offer SIP = trunks, or SIP access of any kind. Just POTS and PRIs. The theory = espoused on this list has been: such networks generate relatively good = caller-IDs. So even for an out-of-band approach, I don't see them = getting certs, or using them, or verifying anything. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From hadriel.kaplan@oracle.com Wed Jun 19 18:18: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 169A421F9F15 for ; Wed, 19 Jun 2013 18:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ogCPmQGfEF+u for ; Wed, 19 Jun 2013 18:18:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7F60521F9F04 for ; Wed, 19 Jun 2013 18:18: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 r5K1IV8X002545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 01:18:32 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 r5K1IT7h022552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 01:18:30 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 r5K1ITu2027958; Thu, 20 Jun 2013 01:18:29 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 18:18:29 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 19 Jun 2013 21:18:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jon Peterson , Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 01:18:52 -0000 Let's take a step back for a second. You believe an out-of-band mechanism can be made to work well. You = believe that it can avoid the problems of SS7, B2BUAs, etc., in the = middle. You believe that it can and will be successfully deployed and = used, and will be deployed and useful before an in-band mechanism = already handles things sufficiently end-to-end. So I gotta ask: why would you advocate doing an in-band approach at all = for this new WG, let alone doing it first before an out-of-band one?? I mean, given those beliefs for an out-of-band solution are true, the = out-of-band solution should be able to handle pure end-to-end SIP calls = too. Right? So why would the IETF ever need or want an in-band = solution? If people are going to deploy and use an out-of-band one = eventually anyway, why should they bother deploying an in-band one that = is purportedly inferior? I mean it seems like a lot of people are going to be spending a lot of = effort on whatever we do - not just effort in the IETF writing RFCs, but = also in development, testing, documentation, training, deployment, = evangelizing, communicating with other SDOs, etc. Writing RFCs is the = easy part really. If you feel an in-band solution is insufficient to solve the problem at = hand, then why should we spend so much effort on it if we're going to = start all over again afterwards? If, on the other hand, doing an in-band solution is sufficient to solve = the problem at hand, why would we do something else afterwards? For = posterity? -hadriel On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >=20 > I don't think anyone here is particularly interested in retreading = this > debate; I think we all agree STIR would be adopting a signature = algorithm > that differs from RFC4474 in a way that is intended to make it = possible > for it to survive SBCs. >=20 > I think how I'd cast what I think Brian was getting it was more like = this: > there are going to be forms of B2BUAs, like PSTN gateways, maybe = gateways > associated with other standard or proprietary protocols, whatever, = that > are going to effectively remove the Identity headers no matter how > friendly we make them. That's just a fact of life. We want to try to > arrange things so that it won't happen as a part of ordinary SBC > operation, but again, I think the problem space of robocalling = involves > all kinds of use cases where SIP is only used over part of the call = path, > or potentially even none of it. The secure-origins-ps draft lists many > scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >=20 > If we had some capability to let the originating and terminating side > verify, more securely than what would get from hop-by-hop trust, that = a > call setup attempt from the originating number is in place, a = capability > that could work around these kinds of extremely adverse B2BUA = conditions, > it would help the impersonation problem. Those of us who spun our = gears on > the VIPR problem for a while know that this isn't trivial, but VIPR is = at > least one (implemented and even deployed, though not widely used) = example > of how Internet endpoints could discover one another as endpoints of a > call and use that out-of-band connection to enhance identity and = security. >=20 > Clearly the knobs were not set in an ideal position for VIPR, so what = we > want to explore is ways of addressing the problem space that will be = more > likely to succeed. In part, that will extracting components out of the > very vertical and monolithic VIPR proposal: the CDS straw men are = examples > of what one of those components would look like (roughly taking the = place > of the VIPR DHT). I think many of us feel that the smartphone = revolution > has created some new opportunities in this space that weren't around = when > we first started working on all this. The way the charter is = structured, > this out-of-band deliverable is placed after the we get done with the > Identity signature revisitation, so I don't think this would be the = first > order of business. I do however think that we should define how that > system will interface with Identity, and how the credentials of the > systems are related (or different), and that it belongs in the scope = of > STIR. >=20 > Jon Peterson > Neustar, Inc. >=20 From hgs@cs.columbia.edu Wed Jun 19 19:27: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 DE54121F9FDE for ; Wed, 19 Jun 2013 19:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 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 sQrORhS5WBsx for ; Wed, 19 Jun 2013 19:27:49 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB221F9BF0 for ; Wed, 19 Jun 2013 19:27:48 -0700 (PDT) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5K2Rk2B024044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Jun 2013 22:27:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4BED381F-553B-4425-A4B0-A47511A433E4@neustar.biz> Date: Wed, 19 Jun 2013 22:27:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <885B307C-C879-43C3-80CD-6E5DA3CB0A2A@cs.columbia.edu> References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> <4BED381F-553B-4425-A4B0-A47511A433E4@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "stir@ietf.org" , "Dwight, Timothy M \(Tim\)" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 02:27:54 -0000 >>=20 >> #4: Is there any actual data behind this initiative? I don't recall = seeing any numbers (e.g., how often do various types of bad things, = happen; what damage is done; is it on the rise or decline). I don't = recall any assessment of how these things are being done (just = assumptions that they're facilitated by spoofing caller ID in a VoIP = call origination). Yes, I know there are web sites you can go to that = let you do exactly that. But do we know that that's how this mischief = is being done? What if it's being initiated on a circuit switched PBX = connected into the POTS network via a PRI, and the culprits are = leveraging gaps in the interworking of ISUP and SIP to go undetected? = If it's knowable we ought to try and know, so that we fix the right = problem. I don't recall any analysis of the [in]adequacy of currently = defined mechanisms. Why for example does transitive trust seem to work = in the PSTN but not in SIP? > I don't have numbers. Henning might. I know that some specific = offenders have been traced and found, and they were using VoIP on their = side. No numbers, but all known offenders are indeed VoIP, as the cost = properties make the "business model" of robocallers work far better than = ISDN-equipped boiler rooms. Also, SS7 entities are usually regulated = entities. Bad actors can be more readily identified, tend to be within = the same country and have a legitimate fear that their (state) = certificate of public convenience and necessity is put in jeopardy. = There are also prohibitions against "phantom calls". My presentation with background is at http://www.cs.columbia.edu/~hgs/papers/2013/2013-source-identity.pptx Needless to say, if we can solve SS7 issues as well, so much the better. = I see those as largely orthogonal. Henning= From philippe.fouquart@orange.com Thu Jun 20 02:37: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 7628821E80F8 for ; Thu, 20 Jun 2013 02:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 aimxlpfHXcfU for ; Thu, 20 Jun 2013 02:37:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0A61D21E810F for ; Thu, 20 Jun 2013 02:37:41 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C8E583B568B; Thu, 20 Jun 2013 11:37:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A948A27C07B; Thu, 20 Jun 2013 11:37:40 +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; Thu, 20 Jun 2013 11:37:40 +0200 From: To: "Rosen, Brian" Thread-Topic: URI formats (was RE: [stir] Do we agree on the basics?) Thread-Index: AQHObZnOf40CKCygkk6na+vByVzuLQ== Date: Thu, 20 Jun 2013 09:37:39 +0000 Message-ID: <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> In-Reply-To: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] 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.20.62421 Cc: "stir@ietf.org" Subject: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 09:37:48 -0000 OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@example.com= ) Does this fall into your "based on delegation of the number" category or = on the "domain entry in the DNS" one? I guess you're going to tell me that it's a "domain based identity" where t= he user just happens to be digits :) I'm not arguing one way or another and have some sympathy with Paul's obser= vation below; but I also realize as others did that we see loads of them in= real life (always treated as phone numbers I mean). My guess is that in a = stir environment two sip URIs sharing the same canonical form as I believe = those two do (with and without user=3Dphone), could be treated as the same = by the (called) endpoint though.=20=20=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of P= aul Kyzivat > Sent: Monday, June 10, 2013 10:49 PM > To: stir@ietf.org > Subject: Re: [stir] Can canonical phone numbers survive SBCs and other mi= ddle boxes? > [snip]=20 > I only bring this up because we may need to consider the implications of= =20 > one or the other. IMO sip:+19785551212@example.com is a private uri=20 > belonging to example.com. It may be intended by example.com to represent= =20 > a phone number, but I don't think anyone without special knowledge of=20 > example.com's policies can trust that assumption. Certainly example.com= =20 > is free to use such a URI even if it has no rights to that phone number. [snip] Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Wednesday, June 19, 2013 7:24 PM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] Do we agree on the basics? "domain based identities" =3D identities of the form sip:user@example.com. It DOES NOT include TN@example.com;user=3Dphone Brian On Jun 19, 2013, at 12:12 PM, wrote: > This looks good to me, thanks for summing this up. For the record, I shar= e the observations/reservations that have already been made on point 5 for = the out-of-band mechanism and the practicalities of a gradual deployment.= =20=20 >=20 > The other thing that slightly puzzles me (and that I don't quite see in o= ther comments) is the statement about "identities that are domain based" ("= the credentials are based on the domain entry in the DNS "). Given that the= proposed charter doesn't talk about what is meant to be in scope in terms = of URI format and what isn't, maybe this exercise will be necessary at some= point to move forward (or if this ""domain-based identity" is meant to cla= rify this, my apologies, I don't quite get it.)=20 >=20 > This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.co= m;user=3Dphone to be validated by the endpoint, the host part must remain u= ntouched end-to-end since, if I read the above correctly, the credentials f= or +CC-XXXXXX will have to be found under domain.com (and I don't mean this= literally in the DNS). Is this correct? (incidentally to me this clearly r= estricts the use case to calling party numbers, your point 2., since for ca= lled parties as others have pointed out, in some networks, the host part is= generally for good or bad irrelevant when the SIP URI conveys an encapsula= ted tel)=20 >=20 > 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= osen, Brian > Sent: Wednesday, June 19, 2013 3:52 PM > To: stir@ietf.org > Subject: [stir] Do we agree on the basics? >=20 > A lot of our discussion is focussed on where certs are found. I want to = make sure that we agree on the basics, because where certs are found is pre= tty far down the list of things to agree on. >=20 > So, do we agree: > 1. The PROBLEM we're solving is robocalling, vishing and swatting > 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURC= E of the call, because we believe that spoofing identity or non providing i= dentity is the way the bad calls are being placed. > 3. The METHOD we're going to use is to pick some data from the call and s= ign or encrypt it in a way that a downstream entity can verify that the inf= ormation is valid > 4. The CREDENTIALS we're going to use, for identities that are telephone = numbers, is based on delegation of the number, rooted in the national numbe= ring authority. For identities that are domain based, the credentials are = based on the domain entry in the DNS. > 5. We think we need two MECHANISMS, an in-band mechanism that has the ori= ginating device or service provider signing information and carries the sig= nature in the signaling. The other is some out of band mechanism that invo= lves some new database or service that gets written by the originating devi= ce or service provider and checked by some downstream entity. The latter m= echanism is needed to allow the identity to be assured even if the informat= ion or signature from the in band mechanism is lost (such as when the call = goes through an SS7 hop). > 6. The credentials (4) are the same in both mechanisms (5) >=20 >=20 > That doesn't say things like where the certs are or what is signed, or wh= at the out of band mechanism does. >=20 > So, I ask, do you agree with that? >=20 > Brian > _______________________________________________ > 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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From brian.rosen@neustar.biz Thu Jun 20 06:47: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 341D721F9C10 for ; Thu, 20 Jun 2013 06:47:09 -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_24=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 8IsnfhSMnWw0 for ; Thu, 20 Jun 2013 06:47:05 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id AECD721F9815 for ; Thu, 20 Jun 2013 06:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371736497; x=1687094615; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=vP/KQw4CXd m3xe+jSO+k/EXOJCFTRMrSAfUOr6PolRA=; b=TTOCoTarTU9GeyUqK6gXrc3iUn NKrE0NJFTF8XkscvDvVYBKgYtL0R0StHdA3YJPnD9+a4/xHBbtjF7ABHcQMA== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26596558; Thu, 20 Jun 2013 09:54:56 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 09:46:35 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] Out of band Thread-Index: AQHObRIXlMwHB1Vzn025u7Vd5O/gB5k9wD8AgAASwACAAQ8SAA== Date: Thu, 20 Jun 2013 13:46:34 +0000 Message-ID: <61BDA3C1-70E8-458A-9F38-8C6F76DE0E80@neustar.biz> References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> In-Reply-To: <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: bIvDnEIBx60RnpRrpj4afQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <750A294474EF834BA6380CE76BA93216@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 13:47:09 -0000 You misunderstood what I said, sorry for my part of the confusion. What I meant was, no matter what we do, we are sure to have some SBCs mangl= ing whatever we need. It's inevitable. =20 I understand that what 4474 does is incompatible with how real networks are= run, and we need to change the approach. I believe we are discussing a ca= nonical e.164 From and To, a timestamp and perhaps the INSIPID call id. =20 I did not mean to imply that all SBCs will forever frustrate solving the pr= oblem. Brian On Jun 19, 2013, at 5:36 PM, Hadriel Kaplan wro= te: >=20 > On Jun 19, 2013, at 4:29 PM, "Rosen, Brian" wro= te: >=20 >>=20 >> On Jun 19, 2013, at 1:25 PM, Dave Crocker wrote: >>=20 >>> On 6/19/2013 10:21 AM, Rosen, Brian wrote: >>>> To be fair, there are some scenarios other than SS7 links where the in= formation is lost. If we go for an SS7-only solution, we don't cover those= cases. The mechanisms may be able to be used in other environments. >>>=20 >>> What scenarios, specifically? >> An SBC that mangles the headers that were originally signed >=20 >=20 > Ugh, this is like deja vu all over again. The reasons why an SBC *should= * "mangle" the headers has been explained numerous times. The reasons why = most users should actually *want* them to be "mangled" by SBCs has been exp= lained numerous times. And the reasons why those headers aren't *necessary= * to sign have also been explained numerous times. >=20 > Some of the info the SBC "mangles" is changed to actually make the call *= work*, or because the owners of them *want* those fields to be changed. Se= nding them un-changed in an out-of-band channel won't mean anything to the = receiver of the call: it won't provide assurance of anything, and can't be = used directly. >=20 > For example, 4474 signs the SDP body. One of the purported reasons it do= es this is to protect the IP:port info of the media because it identifies t= he caller's media. Let's ignore the fact that an IP address is not a user = identity, and that RTP over UDP traffic is trivial to spoof, and that it do= esn't actually identify the end host most of the time due to NATs/Firewalls= anyway... let's instead just assume this IP:port SDP info reaches the far-= end destination of the call in this out-of-band channel. What would this I= P Address actually mean?? It's not usable, because it's highly likely to b= e a private IP Address in someone else's private network. And its not wher= e the media will actually come from or go to, because the media needs to go= to the SBC instead. So what good does it do you to get it?? >=20 > Or another example is 4474 signing the Contact. The claimed reason for t= his was to prevent a MitM from changing the Contact such that it would be a= ble to intercept future messages. Again, let's ignore the fact it doesn't = actually prevent the attack threat, because a MitM can insert Record-Routes= all day long to achieve the same goal... let's just assume the Contact rea= ches the far-end in an out-of-band channel. What would it mean to you? Wh= at would you use it for? And why should I let you learn my Contact URI, wh= ich typically contains my host IP Address? SBCs change it in order to (1) = make call scenarios work right, because certain call scenarios cannot work = without changing the contact, and more importantly (2) to protect each part= y by hiding their IP Addresses;, because if someone calls my house, I don't= expect that someone to learn my IP Address just because my phone rings or = my answering machine answers; or vice-versa, if I call someone else I don't= expect them to l > earn my IP Address just because I called them. >=20 > And some of the info the SBC "mangles" isn't actually necessary for an id= entity verification mechanism to work. For example the Call-ID. It's sign= ed by 4474 as a means of preventing replay. But we know it didn't have to = be, that a different field could have been created for that purpose instead= . It was simply *convenient* to use it for 4474. >=20 > Let's face it: we screwed up with 4474. We knew the problems with it, we= had the debates about it, and we ignored the problems in the hope that the= World would change to accommodate the IETF's vision. It didn't. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From brian.rosen@neustar.biz Thu Jun 20 06: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 037F121F9BA4 for ; Thu, 20 Jun 2013 06:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_42=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 4zJnRp2SbAFj for ; Thu, 20 Jun 2013 06:51:43 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B72DC21F9BA3 for ; Thu, 20 Jun 2013 06:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371736482; x=1687095747; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=7rnRZiRLc/ A83GvkRrPoWfJPD2Ki6vHMLIMOwYqI0XA=; b=EwyvxdGs3PSkrkd1BtveTKNEJ7 ifRjVtuUMqK9nqFGM7ZsBY2Rtrr/KBvv+8cMO0gQ3rIGp1dGJDNdVhDbpn8w== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25422667; Thu, 20 Jun 2013 09:54:41 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 09:51:38 -0400 From: "Rosen, Brian" To: "philippe.fouquart@orange.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObb1Irceg+8rbrkSvrqRLwReGiA== Date: Thu, 20 Jun 2013 13:51:37 +0000 Message-ID: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: g63iQSz+Mj9b2meKS8/z1g== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 13:51:47 -0000 It's not clear to me how any downstream entity is supposed to route a call = like that. If they follow RFCs, then they would route it to example.com. If in fact they route it based on the +CC-YYYY e.164, then it's in scope as= a TN based delegation cert. Brian On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: > OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@example.c= om) Does this fall into your "based on delegation of the number" category o= r on the "domain entry in the DNS" one? >=20 > I guess you're going to tell me that it's a "domain based identity" where= the user just happens to be digits :) >=20 > I'm not arguing one way or another and have some sympathy with Paul's obs= ervation below; but I also realize as others did that we see loads of them = in real life (always treated as phone numbers I mean). My guess is that in = a stir environment two sip URIs sharing the same canonical form as I believ= e those two do (with and without user=3Dphone), could be treated as the sam= e by the (called) endpoint though. =20 >=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Paul Kyzivat >> Sent: Monday, June 10, 2013 10:49 PM >> To: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >=20 > [snip]=20 >=20 >> I only bring this up because we may need to consider the implications of= =20 >> one or the other. IMO sip:+19785551212@example.com is a private uri=20 >> belonging to example.com. It may be intended by example.com to represent= =20 >> a phone number, but I don't think anyone without special knowledge of=20 >> example.com's policies can trust that assumption. Certainly example.com= =20 >> is free to use such a URI even if it has no rights to that phone number. >=20 > [snip] >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Wednesday, June 19, 2013 7:24 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? >=20 > "domain based identities" =3D identities of the form sip:user@example.com= . > It DOES NOT include TN@example.com;user=3Dphone >=20 > Brian > On Jun 19, 2013, at 12:12 PM, wrote: >=20 >> This looks good to me, thanks for summing this up. For the record, I sha= re the observations/reservations that have already been made on point 5 for= the out-of-band mechanism and the practicalities of a gradual deployment. = =20 >>=20 >> The other thing that slightly puzzles me (and that I don't quite see in = other comments) is the statement about "identities that are domain based" (= "the credentials are based on the domain entry in the DNS "). Given that th= e proposed charter doesn't talk about what is meant to be in scope in terms= of URI format and what isn't, maybe this exercise will be necessary at som= e point to move forward (or if this ""domain-based identity" is meant to cl= arify this, my apologies, I don't quite get it.)=20 >>=20 >> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.c= om;user=3Dphone to be validated by the endpoint, the host part must remain = untouched end-to-end since, if I read the above correctly, the credentials = for +CC-XXXXXX will have to be found under domain.com (and I don't mean thi= s literally in the DNS). Is this correct? (incidentally to me this clearly = restricts the use case to calling party numbers, your point 2., since for c= alled parties as others have pointed out, in some networks, the host part i= s generally for good or bad irrelevant when the SIP URI conveys an encapsul= ated tel)=20 >>=20 >> 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 = Rosen, Brian >> Sent: Wednesday, June 19, 2013 3:52 PM >> To: stir@ietf.org >> Subject: [stir] Do we agree on the basics? >>=20 >> A lot of our discussion is focussed on where certs are found. I want to= make sure that we agree on the basics, because where certs are found is pr= etty far down the list of things to agree on. >>=20 >> So, do we agree: >> 1. The PROBLEM we're solving is robocalling, vishing and swatting >> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOUR= CE of the call, because we believe that spoofing identity or non providing = identity is the way the bad calls are being placed. >> 3. The METHOD we're going to use is to pick some data from the call and = sign or encrypt it in a way that a downstream entity can verify that the in= formation is valid >> 4. The CREDENTIALS we're going to use, for identities that are telephone= numbers, is based on delegation of the number, rooted in the national numb= ering authority. For identities that are domain based, the credentials are= based on the domain entry in the DNS. >> 5. We think we need two MECHANISMS, an in-band mechanism that has the or= iginating device or service provider signing information and carries the si= gnature in the signaling. The other is some out of band mechanism that inv= olves some new database or service that gets written by the originating dev= ice or service provider and checked by some downstream entity. The latter = mechanism is needed to allow the identity to be assured even if the informa= tion or signature from the in band mechanism is lost (such as when the call= goes through an SS7 hop). >> 6. The credentials (4) are the same in both mechanisms (5) >>=20 >>=20 >> That doesn't say things like where the certs are or what is signed, or w= hat the out of band mechanism does. >>=20 >> So, I ask, do you agree with that? >>=20 >> Brian >> _______________________________________________ >> 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 confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Thu Jun 20 07:05: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 89CE821F90E4 for ; Thu, 20 Jun 2013 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.316 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 WplkIbV1p+gG for ; Thu, 20 Jun 2013 07:05:46 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48321F9C59 for ; Thu, 20 Jun 2013 07:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=BxxMMAWxU2F9takN1lBRfOa7UkhlfnSxSDm4CPz+k3k=; b=LFfTVHBSxIzrQxEWyd4ymRBsUdk+nkOPnz0KCxd2DxKaDRXROFbrBorsZJZLj9WCg9EjenIfZvdNEkwyqdfOi1at/C/+7wQumxSNIAJfFcg/tgfF0YE0qPwBdvsBr2EknO5vLWznGrCUPmQZxo0Ag4eGg1WT+2a9xN2YU7xCdvY=; Received: from neustargw.va.neustar.com ([209.173.53.233]:41835 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UpfUe-0003u6-K5; Thu, 20 Jun 2013 10:05:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Thu, 20 Jun 2013 10:05:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 14:05:51 -0000 Because we have increasing instances of calls that don't go through SS7 = links. Most of them are effectively "on-net", or between smaller = service providers. We will have, soon enough, IMS based interchange. = We would expect services like Skype to be able to use these mechanisms. Eventually, the things that are inhibiting direct SIP interconnect will = get solved. It won't be a flag day, but it will happen gradually.=20 The bad guys will exploit whatever holes we leave them, so we need to = cover both bases for a while. EKR's idea has some longer term value. My gateway idea is just a = temporary work around for a temporary problem. Brian On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan = wrote: >=20 > Let's take a step back for a second. >=20 > You believe an out-of-band mechanism can be made to work well. You = believe that it can avoid the problems of SS7, B2BUAs, etc., in the = middle. You believe that it can and will be successfully deployed and = used, and will be deployed and useful before an in-band mechanism = already handles things sufficiently end-to-end. >=20 > So I gotta ask: why would you advocate doing an in-band approach at = all for this new WG, let alone doing it first before an out-of-band = one?? >=20 > I mean, given those beliefs for an out-of-band solution are true, the = out-of-band solution should be able to handle pure end-to-end SIP calls = too. Right? So why would the IETF ever need or want an in-band = solution? If people are going to deploy and use an out-of-band one = eventually anyway, why should they bother deploying an in-band one that = is purportedly inferior? >=20 > I mean it seems like a lot of people are going to be spending a lot of = effort on whatever we do - not just effort in the IETF writing RFCs, but = also in development, testing, documentation, training, deployment, = evangelizing, communicating with other SDOs, etc. Writing RFCs is the = easy part really. >=20 > If you feel an in-band solution is insufficient to solve the problem = at hand, then why should we spend so much effort on it if we're going to = start all over again afterwards? >=20 > If, on the other hand, doing an in-band solution is sufficient to = solve the problem at hand, why would we do something else afterwards? = For posterity? >=20 > -hadriel >=20 >=20 > On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >=20 >>=20 >> I don't think anyone here is particularly interested in retreading = this >> debate; I think we all agree STIR would be adopting a signature = algorithm >> that differs from RFC4474 in a way that is intended to make it = possible >> for it to survive SBCs. >>=20 >> I think how I'd cast what I think Brian was getting it was more like = this: >> there are going to be forms of B2BUAs, like PSTN gateways, maybe = gateways >> associated with other standard or proprietary protocols, whatever, = that >> are going to effectively remove the Identity headers no matter how >> friendly we make them. That's just a fact of life. We want to try to >> arrange things so that it won't happen as a part of ordinary SBC >> operation, but again, I think the problem space of robocalling = involves >> all kinds of use cases where SIP is only used over part of the call = path, >> or potentially even none of it. The secure-origins-ps draft lists = many >> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>=20 >> If we had some capability to let the originating and terminating side >> verify, more securely than what would get from hop-by-hop trust, that = a >> call setup attempt from the originating number is in place, a = capability >> that could work around these kinds of extremely adverse B2BUA = conditions, >> it would help the impersonation problem. Those of us who spun our = gears on >> the VIPR problem for a while know that this isn't trivial, but VIPR = is at >> least one (implemented and even deployed, though not widely used) = example >> of how Internet endpoints could discover one another as endpoints of = a >> call and use that out-of-band connection to enhance identity and = security. >>=20 >> Clearly the knobs were not set in an ideal position for VIPR, so what = we >> want to explore is ways of addressing the problem space that will be = more >> likely to succeed. In part, that will extracting components out of = the >> very vertical and monolithic VIPR proposal: the CDS straw men are = examples >> of what one of those components would look like (roughly taking the = place >> of the VIPR DHT). I think many of us feel that the smartphone = revolution >> has created some new opportunities in this space that weren't around = when >> we first started working on all this. The way the charter is = structured, >> this out-of-band deliverable is placed after the we get done with the >> Identity signature revisitation, so I don't think this would be the = first >> order of business. I do however think that we should define how that >> system will interface with Identity, and how the credentials of the >> systems are related (or different), and that it belongs in the scope = of >> STIR. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >=20 From philippe.fouquart@orange.com Thu Jun 20 07:18: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 0A38321F9C31 for ; Thu, 20 Jun 2013 07:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 A3jEKaxLrDjZ for ; Thu, 20 Jun 2013 07:17:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49121F9BD4 for ; Thu, 20 Jun 2013 07:17:58 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2024A3B519F; Thu, 20 Jun 2013 16:17:57 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0224F4C077; Thu, 20 Jun 2013 16:17:57 +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, 20 Jun 2013 16:17:56 +0200 From: To: "Rosen, Brian" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaA= Date: Thu, 20 Jun 2013 14:17:55 +0000 Message-ID: <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> In-Reply-To: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] 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.20.130322 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 14:18:03 -0000 OK. In a Request-URI (I was thinking more of it in a From given the context= ) with a + sign upfront, the entities I'm familiar with would route it base= d on the TN and without it, some may even also do the same. One may argue t= hat those entities are not meant to support anything else than TN-based ses= sions anyway.=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, June 20, 2013 3:52 PM To: FOUQUART Philippe OLNC/OLN Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) It's not clear to me how any downstream entity is supposed to route a call = like that. If they follow RFCs, then they would route it to example.com. If in fact they route it based on the +CC-YYYY e.164, then it's in scope as= a TN based delegation cert. Brian On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: > OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@example.c= om) Does this fall into your "based on delegation of the number" category o= r on the "domain entry in the DNS" one? >=20 > I guess you're going to tell me that it's a "domain based identity" where= the user just happens to be digits :) >=20 > I'm not arguing one way or another and have some sympathy with Paul's obs= ervation below; but I also realize as others did that we see loads of them = in real life (always treated as phone numbers I mean). My guess is that in = a stir environment two sip URIs sharing the same canonical form as I believ= e those two do (with and without user=3Dphone), could be treated as the sam= e by the (called) endpoint though.=20=20=20 >=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Paul Kyzivat >> Sent: Monday, June 10, 2013 10:49 PM >> To: stir@ietf.org >> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other m= iddle boxes? >>=20 >=20 > [snip]=20 >=20 >> I only bring this up because we may need to consider the implications of= =20 >> one or the other. IMO sip:+19785551212@example.com is a private uri=20 >> belonging to example.com. It may be intended by example.com to represent= =20 >> a phone number, but I don't think anyone without special knowledge of=20 >> example.com's policies can trust that assumption. Certainly example.com= =20 >> is free to use such a URI even if it has no rights to that phone number. >=20 > [snip] >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Wednesday, June 19, 2013 7:24 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] Do we agree on the basics? >=20 > "domain based identities" =3D identities of the form sip:user@example.com. > It DOES NOT include TN@example.com;user=3Dphone >=20 > Brian > On Jun 19, 2013, at 12:12 PM, wrote: >=20 >> This looks good to me, thanks for summing this up. For the record, I sha= re the observations/reservations that have already been made on point 5 for= the out-of-band mechanism and the practicalities of a gradual deployment.= =20=20 >>=20 >> The other thing that slightly puzzles me (and that I don't quite see in = other comments) is the statement about "identities that are domain based" (= "the credentials are based on the domain entry in the DNS "). Given that th= e proposed charter doesn't talk about what is meant to be in scope in terms= of URI format and what isn't, maybe this exercise will be necessary at som= e point to move forward (or if this ""domain-based identity" is meant to cl= arify this, my apologies, I don't quite get it.)=20 >>=20 >> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.c= om;user=3Dphone to be validated by the endpoint, the host part must remain = untouched end-to-end since, if I read the above correctly, the credentials = for +CC-XXXXXX will have to be found under domain.com (and I don't mean thi= s literally in the DNS). Is this correct? (incidentally to me this clearly = restricts the use case to calling party numbers, your point 2., since for c= alled parties as others have pointed out, in some networks, the host part i= s generally for good or bad irrelevant when the SIP URI conveys an encapsul= ated tel)=20 >>=20 >> 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 = Rosen, Brian >> Sent: Wednesday, June 19, 2013 3:52 PM >> To: stir@ietf.org >> Subject: [stir] Do we agree on the basics? >>=20 >> A lot of our discussion is focussed on where certs are found. I want to= make sure that we agree on the basics, because where certs are found is pr= etty far down the list of things to agree on. >>=20 >> So, do we agree: >> 1. The PROBLEM we're solving is robocalling, vishing and swatting >> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOUR= CE of the call, because we believe that spoofing identity or non providing = identity is the way the bad calls are being placed. >> 3. The METHOD we're going to use is to pick some data from the call and = sign or encrypt it in a way that a downstream entity can verify that the in= formation is valid >> 4. The CREDENTIALS we're going to use, for identities that are telephone= numbers, is based on delegation of the number, rooted in the national numb= ering authority. For identities that are domain based, the credentials are= based on the domain entry in the DNS. >> 5. We think we need two MECHANISMS, an in-band mechanism that has the or= iginating device or service provider signing information and carries the si= gnature in the signaling. The other is some out of band mechanism that inv= olves some new database or service that gets written by the originating dev= ice or service provider and checked by some downstream entity. The latter = mechanism is needed to allow the identity to be assured even if the informa= tion or signature from the in band mechanism is lost (such as when the call= goes through an SS7 hop). >> 6. The credentials (4) are the same in both mechanisms (5) >>=20 >>=20 >> That doesn't say things like where the certs are or what is signed, or w= hat the out of band mechanism does. >>=20 >> So, I ask, do you agree with that? >>=20 >> Brian >> _______________________________________________ >> 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 confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From timothy.dwight@verizon.com Thu Jun 20 08:12: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 E4D5321F9D17 for ; Thu, 20 Jun 2013 08:12:35 -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=[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 G04AC5CnL0oc for ; Thu, 20 Jun 2013 08:12:24 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1237E21F9DF3 for ; Thu, 20 Jun 2013 08:12:19 -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; 20 Jun 2013 15:12:17 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,905,1363132800"; d="scan'208";a="493657520" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 20 Jun 2013 15:12:17 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 20 Jun 2013 11:12:16 -0400 To: Henning Schulzrinne , "Rosen, Brian" Date: Thu, 20 Jun 2013 11:12:15 -0400 Thread-Topic: [stir] Do we agree on the basics? Thread-Index: Ac5tXcM97XgNLmgfTb6ciR08wvkejwAW/Xww Message-ID: <2B0F677F0B95454297753F58D4A07FA30127D946AA@FHDP1LUMXC7V31.us.one.verizon.com> References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> <4BED381F-553B-4425-A4B0-A47511A433E4@neustar.biz> <885B307C-C879-43C3-80CD-6E5DA3CB0A2A@cs.columbia.edu> In-Reply-To: <885B307C-C879-43C3-80CD-6E5DA3CB0A2A@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 15:12:57 -0000 Thanks, Henning. The slides are helpful. A couple of observations. 1) The set of mischievous actions enabled by anonymization seem equally ena= bled by simply omitting the calling party number (CPN). In theory Anonymou= s Call Rejection (ACR) protects from the latter, but because so many calls = fail to specify a valid CPN, few people use ACR. They'd simply miss too ma= ny calls. Point being that our solution needs to explicitly address this c= ase. Here's a very practical reason why: although nobody seems to know ho= w "big" the explicitly-signaled-invalid-CPN problem is, we do know how big = the lack-of-valid-CPN problem is. That helps when it comes time to build t= he case to deploy something. 2) We seem to have leapt quickly to a solution. Were others considered and= discarded? If so can a summary of ideas-not-pursued, be provided? Basica= lly I'm looking for a summary of the normal problem analysis and solution r= equirements activities, so that I can understand why the solution being pro= moted is the best possible (or at least a reasonable) solution. tim -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, June 19, 2013 9:28 PM To: Rosen, Brian Cc: Dwight, Timothy M (Tim); stir@ietf.org Subject: Re: [stir] Do we agree on the basics? >>=20 >> #4: Is there any actual data behind this initiative? I don't recall se= eing any numbers (e.g., how often do various types of bad things, happen; w= hat damage is done; is it on the rise or decline). I don't recall any asse= ssment of how these things are being done (just assumptions that they're fa= cilitated by spoofing caller ID in a VoIP call origination). Yes, I know t= here are web sites you can go to that let you do exactly that. But do we k= now that that's how this mischief is being done? What if it's being initia= ted on a circuit switched PBX connected into the POTS network via a PRI, an= d the culprits are leveraging gaps in the interworking of ISUP and SIP to g= o undetected? If it's knowable we ought to try and know, so that we fix th= e right problem. I don't recall any analysis of the [in]adequacy of curren= tly defined mechanisms. Why for example does transitive trust seem to work= in the PSTN but not in SIP? > I don't have numbers. Henning might. I know that some specific offender= s have been traced and found, and they were using VoIP on their side. No numbers, but all known offenders are indeed VoIP, as the cost properties= make the "business model" of robocallers work far better than ISDN-equippe= d boiler rooms. Also, SS7 entities are usually regulated entities. Bad acto= rs can be more readily identified, tend to be within the same country and h= ave a legitimate fear that their (state) certificate of public convenience = and necessity is put in jeopardy. There are also prohibitions against "phan= tom calls". My presentation with background is at http://www.cs.columbia.edu/~hgs/papers/2013/2013-source-identity.pptx Needless to say, if we can solve SS7 issues as well, so much the better. I = see those as largely orthogonal. Henning From hadriel.kaplan@oracle.com Thu Jun 20 09:41: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 42A3021F9D90 for ; Thu, 20 Jun 2013 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_42=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 FxNvJ80vNLA6 for ; Thu, 20 Jun 2013 09:41:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33921F9A58 for ; Thu, 20 Jun 2013 09:41:18 -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 r5KGYx7w011583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 16:35: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 r5KGfFoe014490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 16:41:16 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 r5KGfF6Z004468; Thu, 20 Jun 2013 16:41:15 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 09:41:15 -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: <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 20 Jun 2013 12:41:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 16:41:24 -0000 I don't think it matters at all whether there's a 'user=3Dphone' param = or not. Brian's right that that's what *should* be in the URI, but we = all know that isn't what happens on-the-wire. Whether there's a = 'user=3Dphone' or not, or even a leading '+' or not, if the user portion = of the URI looks like a phone number and smells like a phone number, its = treated as a phone number by virtually everyone. It's been that way for = many years in SIP. At a high level, it doesn't matter how something appears on-the-wire. = If the terminating domain *treats* it as a phone number, and displays to = the user only a phone number caller-id, then we need to validate it as a = phone number. Otherwise, if foo.com sends a =46rom URI of = 'sip:330145295813@foo.com', and STIR treats it as an email-style name = instead of E.164, but your phone displays '330145295813', then foo.com = will have successfully spoofed your number. The really important point/concept Brian made in another email thread = earlier, I think, was the idea of determining a canonical E.164 number = from the To/=46rom URIs. One of his points there was that sure the = encoded number in the URI may have a prefix of digits, or is missing the = country-code because it's in national form, or it has visual separators = in it, or whatever. But as long as the signer and verifier can both = determine what the "real" E.164 numbers are that they need to = sign/verify, then the actual user string in the URI doesn't matter. At first I thought that idea was crazy - that it would be too hard to = get systems along the path to be able to figure out a canonical E.164 = automatically from random user strings they get in To/=46rom URIs. But = then I realized that actually it's not hard at all, and that in fact = it's done all the time. It may require more-than-trivial configuration, = but ultimately every carrier has to actually do that type of = determination for every call that leaves/enters their domain. Well ok, = they only have to do it for international calls, but the point is a lot = of them do this type of thing already. And it's done by a lot of = systems. Even SBCs do it, using number translations or manipulation = rules or whatever. So if we accept the fact that the signing and verifying domains can and = will do a canonicalization step, I'd argue part of that step is deciding = whether a received To/=46rom URI is actually an E.164 vs. an email-style = name. It would be based on the rules of the domain, and parameters like = 'user=3Dphone' can be ignored if the domain ignores it for routing and = display purposes anyway. -hadriel On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: > OK. In a Request-URI (I was thinking more of it in a =46rom given the = context) with a + sign upfront, the entities I'm familiar with would = route it based on the TN and without it, some may even also do the same. = One may argue that those entities are not meant to support anything else = than TN-based sessions anyway.=20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Thursday, June 20, 2013 3:52 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 > It's not clear to me how any downstream entity is supposed to route a = call like that. If they follow RFCs, then they would route it to = example.com. > If in fact they route it based on the +CC-YYYY e.164, then it's in = scope as a TN based delegation cert. >=20 > Brian > On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >=20 >> OK, good, thanks. And finally what if user=3DTN? = (sip:+CC-YYYYY@example.com) Does this fall into your "based on = delegation of the number" category or on the "domain entry in the DNS" = one? >>=20 >> I guess you're going to tell me that it's a "domain based identity" = where the user just happens to be digits :) >>=20 >> I'm not arguing one way or another and have some sympathy with Paul's = observation below; but I also realize as others did that we see loads of = them in real life (always treated as phone numbers I mean). My guess is = that in a stir environment two sip URIs sharing the same canonical form = as I believe those two do (with and without user=3Dphone), could be = treated as the same by the (called) endpoint though. =20 >>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Paul Kyzivat >>> Sent: Monday, June 10, 2013 10:49 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>=20 >>=20 >> [snip]=20 >>=20 >>> I only bring this up because we may need to consider the = implications of=20 >>> one or the other. IMO sip:+19785551212@example.com is a private uri=20= >>> belonging to example.com. It may be intended by example.com to = represent=20 >>> a phone number, but I don't think anyone without special knowledge = of=20 >>> example.com's policies can trust that assumption. Certainly = example.com=20 >>> is free to use such a URI even if it has no rights to that phone = number. >>=20 >> [snip] >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >> Sent: Wednesday, June 19, 2013 7:24 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] Do we agree on the basics? >>=20 >> "domain based identities" =3D identities of the form = sip:user@example.com. >> It DOES NOT include TN@example.com;user=3Dphone >>=20 >> Brian >> On Jun 19, 2013, at 12:12 PM, wrote: >>=20 >>> This looks good to me, thanks for summing this up. For the record, I = share the observations/reservations that have already been made on point = 5 for the out-of-band mechanism and the practicalities of a gradual = deployment. =20 >>>=20 >>> The other thing that slightly puzzles me (and that I don't quite see = in other comments) is the statement about "identities that are domain = based" ("the credentials are based on the domain entry in the DNS "). = Given that the proposed charter doesn't talk about what is meant to be = in scope in terms of URI format and what isn't, maybe this exercise will = be necessary at some point to move forward (or if this ""domain-based = identity" is meant to clarify this, my apologies, I don't quite get it.)=20= >>>=20 >>> This assumes that for a signed and 'uncorrupted' = sip:+CC-XXXXXX@domain.com;user=3Dphone to be validated by the endpoint, = the host part must remain untouched end-to-end since, if I read the = above correctly, the credentials for +CC-XXXXXX will have to be found = under domain.com (and I don't mean this literally in the DNS). Is this = correct? (incidentally to me this clearly restricts the use case to = calling party numbers, your point 2., since for called parties as others = have pointed out, in some networks, the host part is generally for good = or bad irrelevant when the SIP URI conveys an encapsulated tel)=20 >>>=20 >>> 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 Rosen, Brian >>> Sent: Wednesday, June 19, 2013 3:52 PM >>> To: stir@ietf.org >>> Subject: [stir] Do we agree on the basics? >>>=20 >>> A lot of our discussion is focussed on where certs are found. I = want to make sure that we agree on the basics, because where certs are = found is pretty far down the list of things to agree on. >>>=20 >>> So, do we agree: >>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>> 2. The APPROACH we're going to use is to verify the IDENTITY of the = SOURCE of the call, because we believe that spoofing identity or non = providing identity is the way the bad calls are being placed. >>> 3. The METHOD we're going to use is to pick some data from the call = and sign or encrypt it in a way that a downstream entity can verify that = the information is valid >>> 4. The CREDENTIALS we're going to use, for identities that are = telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. >>> 5. We think we need two MECHANISMS, an in-band mechanism that has = the originating device or service provider signing information and = carries the signature in the signaling. The other is some out of band = mechanism that involves some new database or service that gets written = by the originating device or service provider and checked by some = downstream entity. The latter mechanism is needed to allow the identity = to be assured even if the information or signature from the in band = mechanism is lost (such as when the call goes through an SS7 hop). >>> 6. The credentials (4) are the same in both mechanisms (5) >>>=20 >>>=20 >>> That doesn't say things like where the certs are or what is signed, = or what the out of band mechanism does. >>>=20 >>> So, I ask, do you agree with that? >>>=20 >>> Brian >>> _______________________________________________ >>> 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, >>> France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=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, >> France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=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, > France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Thu Jun 20 10:06: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 EA90B21F9C88 for ; Thu, 20 Jun 2013 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=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 WFXQ3MLwiKeE for ; Thu, 20 Jun 2013 10:06:34 -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 35CC221F9920 for ; Thu, 20 Jun 2013 10:06:32 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta07.westchester.pa.mail.comcast.net with comcast id qblw1l0040SCNGk57h6YMe; Thu, 20 Jun 2013 17:06:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id qh6X1l0133ZTu2S3Vh6YiF; Thu, 20 Jun 2013 17:06:32 +0000 Message-ID: <51C33699.9000308@alum.mit.edu> Date: Thu, 20 Jun 2013 13:06:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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=1371747992; bh=aa5LFvDjkJFuzkWMXGcbuB/DKOsl7b1I59I9qLfwxBQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SFtJunO6u6OQ+x3zuBpxrcwRdZjeNU6wPrYdx+bMh7uufK4HjaEe2/R+RcVLaUJEP o+Il1S15+n9COCrj08plilouuRgMh63sXiNIdKzG6Wd25IIGLiOMXmgcW2I8Tfx8mF uB0kDjGL/tggPsgEG3ohE6A5BNOmWvKDxZJXOmYemxz6nMWrN/HXbBMQATOHk9+Hcu 54bgQ6Epi19e54ocAZqmxcLfDvPdyLxC5soS4xKq6zzg8jmWjeaENrgXh58tvcLdcf 5I76kLXvTZ6oT8+Fomv632Mgjrkbgf1CLIBu85L+cqBfxtLIuWIh6wHd1Z0rt3JHuI gG+OzCoEw7OTw== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:06:39 -0000 On 6/20/13 12:41 PM, Hadriel Kaplan wrote: > > I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call. But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this: - if you route the call to the PSTN, but foo.example.com doesn't have a connection to receive from the PSTN, its a problem. - if the official mapping of the phone number part takes it to some other domain than foo.example.com, that's a problem. - if you route it to the PSTN, and it does make it back to foo.example.com, then it may have lost important properties, like video. - it may be that the user part only coincidentally is made up of digits that you happen to think look like a phone number. If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable. > At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. > > The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. > > At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. > > So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok. Thanks, Paul > -hadriel > > > On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: > >> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >> >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, June 20, 2013 3:52 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >> >> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >> >> Brian >> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >> >>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>> >>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>> >>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>> >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, June 10, 2013 10:49 PM >>>> To: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>> >>> >>> [snip] >>> >>>> I only bring this up because we may need to consider the implications of >>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>> belonging to example.com. It may be intended by example.com to represent >>>> a phone number, but I don't think anyone without special knowledge of >>>> example.com's policies can trust that assumption. Certainly example.com >>>> is free to use such a URI even if it has no rights to that phone number. >>> >>> [snip] >>> >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Wednesday, June 19, 2013 7:24 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Do we agree on the basics? >>> >>> "domain based identities" = identities of the form sip:user@example.com. >>> It DOES NOT include TN@example.com;user=phone >>> >>> Brian >>> On Jun 19, 2013, at 12:12 PM, wrote: >>> >>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>> >>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>> >>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>> >>>> 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 Rosen, Brian >>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Do we agree on the basics? >>>> >>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>> >>>> So, do we agree: >>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>> 6. The credentials (4) are the same in both mechanisms (5) >>>> >>>> >>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>> >>>> So, I ask, do you agree with that? >>>> >>>> Brian >>>> _______________________________________________ >>>> 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, >>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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, >>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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, >> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 Jun 20 10:17: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 4D2CB21F9E5A for ; Thu, 20 Jun 2013 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.024 X-Spam-Level: X-Spam-Status: No, score=-100.024 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.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 3YQg-vlUxm1V for ; Thu, 20 Jun 2013 10:17:53 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFDE21F9E68 for ; Thu, 20 Jun 2013 10:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=LnuEnQUFBj/AV843/tKlnWM/+Cl/GMTwMBzct4Fcqvg=; b=Nczsnv6dQK06YA5WDeMv64gXd7VWk+nFZN547vvXypKIk3ouDVrJUrgc+GIsPDy5unyaJWJ7tjdVEy1MxrKn3mvLsFjZsAnpSFeHkTDqmWCxosgRfmXaJqvCUl/6ta0595TmcVW+1PT5AKmiTCTRFoQcw7uEeHXkhYfGYcwQ9UM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:38555 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UpiUV-00083n-3S; Thu, 20 Jun 2013 13:17:47 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51C33699.9000308@alum.mit.edu> Date: Thu, 20 Jun 2013 13:17:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:17:57 -0000 I think Hadriel got it right - if you will route it based on the phone = number, then use a phone number based identity. If you route it as a = user@domain address, then use a domain based identity. Both ends will = use the same assumptions or the call won't get to the intended = destination. Brian On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: > On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>=20 >> I don't think it matters at all whether there's a 'user=3Dphone' = param or not. Brian's right that that's what *should* be in the URI, = but we all know that isn't what happens on-the-wire. Whether there's a = 'user=3Dphone' or not, or even a leading '+' or not, if the user portion = of the URI looks like a phone number and smells like a phone number, its = treated as a phone number by virtually everyone. It's been that way for = many years in SIP. >=20 > I have no problem with somebody using specific knowledge of how domain = foo.example.com manages user parts to decide that the sip URI with that = domain is a phone number, and then use the phone number to route the = call. >=20 > But it is a serious problem if that is done *without* any knowledge of = the target domain. Some issues with this: > - if you route the call to the PSTN, but foo.example.com doesn't have = a > connection to receive from the PSTN, its a problem. > - if the official mapping of the phone number part takes it to some > other domain than foo.example.com, that's a problem. > - if you route it to the PSTN, and it does make it back to > foo.example.com, then it may have lost important properties, > like video. > - it may be that the user part only coincidentally is made up of > digits that you happen to think look like a phone number. >=20 > If this is considered acceptable behavior, then we have effectively = declared that all user parts that even remotely resemble a phone number = are reserved, and can only be used in cases where gatewaying to PSTN is = acceptable. >=20 >> At a high level, it doesn't matter how something appears on-the-wire. = If the terminating domain *treats* it as a phone number, and displays = to the user only a phone number caller-id, then we need to validate it = as a phone number. Otherwise, if foo.com sends a =46rom URI of = 'sip:330145295813@foo.com', and STIR treats it as an email-style name = instead of E.164, but your phone displays '330145295813', then foo.com = will have successfully spoofed your number. >>=20 >> The really important point/concept Brian made in another email thread = earlier, I think, was the idea of determining a canonical E.164 number = from the To/=46rom URIs. One of his points there was that sure the = encoded number in the URI may have a prefix of digits, or is missing the = country-code because it's in national form, or it has visual separators = in it, or whatever. But as long as the signer and verifier can both = determine what the "real" E.164 numbers are that they need to = sign/verify, then the actual user string in the URI doesn't matter. >>=20 >> At first I thought that idea was crazy - that it would be too hard to = get systems along the path to be able to figure out a canonical E.164 = automatically from random user strings they get in To/=46rom URIs. But = then I realized that actually it's not hard at all, and that in fact = it's done all the time. It may require more-than-trivial configuration, = but ultimately every carrier has to actually do that type of = determination for every call that leaves/enters their domain. Well ok, = they only have to do it for international calls, but the point is a lot = of them do this type of thing already. And it's done by a lot of = systems. Even SBCs do it, using number translations or manipulation = rules or whatever. >>=20 >> So if we accept the fact that the signing and verifying domains can = and will do a canonicalization step, I'd argue part of that step is = deciding whether a received To/=46rom URI is actually an E.164 vs. an = email-style name. It would be based on the rules of the domain, and = parameters like 'user=3Dphone' can be ignored if the domain ignores it = for routing and display purposes anyway. >=20 > So as long as the part about "rules of the domain" really applies, and = it isn't done if the rules of the domain aren't known, then I'm ok. >=20 > Thanks, > Paul >=20 >> -hadriel >>=20 >>=20 >> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>=20 >>> OK. In a Request-URI (I was thinking more of it in a =46rom given = the context) with a + sign upfront, the entities I'm familiar with would = route it based on the TN and without it, some may even also do the same. = One may argue that those entities are not meant to support anything else = than TN-based sessions anyway. >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Thursday, June 20, 2013 3:52 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>=20 >>> It's not clear to me how any downstream entity is supposed to route = a call like that. If they follow RFCs, then they would route it to = example.com. >>> If in fact they route it based on the +CC-YYYY e.164, then it's in = scope as a TN based delegation cert. >>>=20 >>> Brian >>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>=20 >>>> OK, good, thanks. And finally what if user=3DTN? = (sip:+CC-YYYYY@example.com) Does this fall into your "based on = delegation of the number" category or on the "domain entry in the DNS" = one? >>>>=20 >>>> I guess you're going to tell me that it's a "domain based identity" = where the user just happens to be digits :) >>>>=20 >>>> I'm not arguing one way or another and have some sympathy with = Paul's observation below; but I also realize as others did that we see = loads of them in real life (always treated as phone numbers I mean). My = guess is that in a stir environment two sip URIs sharing the same = canonical form as I believe those two do (with and without user=3Dphone), = could be treated as the same by the (called) endpoint though. >>>>=20 >>>>> -----Original Message----- >>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf Of Paul Kyzivat >>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>> To: stir@ietf.org >>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>>>=20 >>>>=20 >>>> [snip] >>>>=20 >>>>> I only bring this up because we may need to consider the = implications of >>>>> one or the other. IMO sip:+19785551212@example.com is a private = uri >>>>> belonging to example.com. It may be intended by example.com to = represent >>>>> a phone number, but I don't think anyone without special knowledge = of >>>>> example.com's policies can trust that assumption. Certainly = example.com >>>>> is free to use such a URI even if it has no rights to that phone = number. >>>>=20 >>>> [snip] >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] Do we agree on the basics? >>>>=20 >>>> "domain based identities" =3D identities of the form = sip:user@example.com. >>>> It DOES NOT include TN@example.com;user=3Dphone >>>>=20 >>>> Brian >>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>=20 >>>>> This looks good to me, thanks for summing this up. For the record, = I share the observations/reservations that have already been made on = point 5 for the out-of-band mechanism and the practicalities of a = gradual deployment. >>>>>=20 >>>>> The other thing that slightly puzzles me (and that I don't quite = see in other comments) is the statement about "identities that are = domain based" ("the credentials are based on the domain entry in the DNS = "). Given that the proposed charter doesn't talk about what is meant to = be in scope in terms of URI format and what isn't, maybe this exercise = will be necessary at some point to move forward (or if this = ""domain-based identity" is meant to clarify this, my apologies, I don't = quite get it.) >>>>>=20 >>>>> This assumes that for a signed and 'uncorrupted' = sip:+CC-XXXXXX@domain.com;user=3Dphone to be validated by the endpoint, = the host part must remain untouched end-to-end since, if I read the = above correctly, the credentials for +CC-XXXXXX will have to be found = under domain.com (and I don't mean this literally in the DNS). Is this = correct? (incidentally to me this clearly restricts the use case to = calling party numbers, your point 2., since for called parties as others = have pointed out, in some networks, the host part is generally for good = or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>=20 >>>>> 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 Rosen, Brian >>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>> To: stir@ietf.org >>>>> Subject: [stir] Do we agree on the basics? >>>>>=20 >>>>> A lot of our discussion is focussed on where certs are found. I = want to make sure that we agree on the basics, because where certs are = found is pretty far down the list of things to agree on. >>>>>=20 >>>>> So, do we agree: >>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of = the SOURCE of the call, because we believe that spoofing identity or non = providing identity is the way the bad calls are being placed. >>>>> 3. The METHOD we're going to use is to pick some data from the = call and sign or encrypt it in a way that a downstream entity can verify = that the information is valid >>>>> 4. The CREDENTIALS we're going to use, for identities that are = telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. >>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has = the originating device or service provider signing information and = carries the signature in the signaling. The other is some out of band = mechanism that involves some new database or service that gets written = by the originating device or service provider and checked by some = downstream entity. The latter mechanism is needed to allow the identity = to be assured even if the information or signature from the in band = mechanism is lost (such as when the call goes through an SS7 hop). >>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>=20 >>>>>=20 >>>>> That doesn't say things like where the certs are or what is = signed, or what the out of band mechanism does. >>>>>=20 >>>>> So, I ask, do you agree with that? >>>>>=20 >>>>> Brian >>>>> _______________________________________________ >>>>> 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, >>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=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, >>>> France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=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, >>> France Telecom - 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>> Thank you. >>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Thu Jun 20 10:23: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 54F4D21F9A52 for ; Thu, 20 Jun 2013 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 chKw4ET2clGQ for ; Thu, 20 Jun 2013 10:23:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59C21F9007 for ; Thu, 20 Jun 2013 10:22:56 -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 r5KHMrsm003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 17:22:54 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 r5KHMr3l019971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 17:22:53 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KHMqQv021927; Thu, 20 Jun 2013 17:22:52 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 10:22: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: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> Date: Thu, 20 Jun 2013 13:22:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:23:19 -0000 OK, but my point was that view is inconsistent. The claims made are = that an out-of-band is basically a completely-overlapping superset of = the in-band: the out-of-band covers all cases, whereas the in-band does = not. The rationale for having an out-of-band is that in the near-term, = we don't have SIP everywhere, so we need the superset out-of-band = solution too. This already implies we need the out-of-band *sooner* = than we need the in-band. But more importantly if the out-of-band is = really possible, and really going to be deployed and used, then why = should we bother doing the in-band at all, ever? Right now you're asking for the charter to cover two mechanisms/models: = an in-band and out-of-band. The claim is it's worth our time and effort = to do both, and that both have their place. I assume the belief is both = would be actually deployed and used, right? I find it very hard to believe that. I think if we can get one = mechanism to be deployed, no one would do anything different. Why would = they?? Why should we spend the huge amount of effort it will take to do = something once, and then do it all over again a second time? My guess is you and Jon think the problem is we need a "stop-gap" = solution that we can quickly specify and deploy, and *that's* what the = in-band is for. But that in the long term we need an out-of-band = solution, and people will switch to that because the in-band won't work = well enough in the long-term. If that's the case, there's an existing solution we can use for a = stop-gap short-term solution: P-Asserted-Identity. No one has ever = shown me a case of P-Asserted-Identity being spoofed. It's not hard to = spoof it, obviously, because it's purely based on transitive trust. It = doesn't work through SS7, but neither would a new in-band approach.[1] = In the long-term it will likely fail, and people will be able to inject = into the trusted networks a false PAI header value that spoofs another = number. But the idea of even a new in-band solution not being good = enough in the long-term must already be believed, for us to believe = people will migrate to an out-of-band approach and make it worth our = time. -hadriel [1] well... we might be able to get an in-band approach to work through = short SS7 connections. Maybe. On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: > Because we have increasing instances of calls that don't go through = SS7 links. Most of them are effectively "on-net", or between smaller = service providers. We will have, soon enough, IMS based interchange. = We would expect services like Skype to be able to use these mechanisms. >=20 > Eventually, the things that are inhibiting direct SIP interconnect = will get solved. >=20 > It won't be a flag day, but it will happen gradually.=20 >=20 > The bad guys will exploit whatever holes we leave them, so we need to = cover both bases for a while. >=20 > EKR's idea has some longer term value. My gateway idea is just a = temporary work around for a temporary problem. >=20 > Brian >=20 > On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> Let's take a step back for a second. >>=20 >> You believe an out-of-band mechanism can be made to work well. You = believe that it can avoid the problems of SS7, B2BUAs, etc., in the = middle. You believe that it can and will be successfully deployed and = used, and will be deployed and useful before an in-band mechanism = already handles things sufficiently end-to-end. >>=20 >> So I gotta ask: why would you advocate doing an in-band approach at = all for this new WG, let alone doing it first before an out-of-band = one?? >>=20 >> I mean, given those beliefs for an out-of-band solution are true, the = out-of-band solution should be able to handle pure end-to-end SIP calls = too. Right? So why would the IETF ever need or want an in-band = solution? If people are going to deploy and use an out-of-band one = eventually anyway, why should they bother deploying an in-band one that = is purportedly inferior? >>=20 >> I mean it seems like a lot of people are going to be spending a lot = of effort on whatever we do - not just effort in the IETF writing RFCs, = but also in development, testing, documentation, training, deployment, = evangelizing, communicating with other SDOs, etc. Writing RFCs is the = easy part really. >>=20 >> If you feel an in-band solution is insufficient to solve the problem = at hand, then why should we spend so much effort on it if we're going to = start all over again afterwards? >>=20 >> If, on the other hand, doing an in-band solution is sufficient to = solve the problem at hand, why would we do something else afterwards? = For posterity? >>=20 >> -hadriel >>=20 >>=20 >> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >>=20 >>>=20 >>> I don't think anyone here is particularly interested in retreading = this >>> debate; I think we all agree STIR would be adopting a signature = algorithm >>> that differs from RFC4474 in a way that is intended to make it = possible >>> for it to survive SBCs. >>>=20 >>> I think how I'd cast what I think Brian was getting it was more like = this: >>> there are going to be forms of B2BUAs, like PSTN gateways, maybe = gateways >>> associated with other standard or proprietary protocols, whatever, = that >>> are going to effectively remove the Identity headers no matter how >>> friendly we make them. That's just a fact of life. We want to try to >>> arrange things so that it won't happen as a part of ordinary SBC >>> operation, but again, I think the problem space of robocalling = involves >>> all kinds of use cases where SIP is only used over part of the call = path, >>> or potentially even none of it. The secure-origins-ps draft lists = many >>> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>>=20 >>> If we had some capability to let the originating and terminating = side >>> verify, more securely than what would get from hop-by-hop trust, = that a >>> call setup attempt from the originating number is in place, a = capability >>> that could work around these kinds of extremely adverse B2BUA = conditions, >>> it would help the impersonation problem. Those of us who spun our = gears on >>> the VIPR problem for a while know that this isn't trivial, but VIPR = is at >>> least one (implemented and even deployed, though not widely used) = example >>> of how Internet endpoints could discover one another as endpoints of = a >>> call and use that out-of-band connection to enhance identity and = security. >>>=20 >>> Clearly the knobs were not set in an ideal position for VIPR, so = what we >>> want to explore is ways of addressing the problem space that will be = more >>> likely to succeed. In part, that will extracting components out of = the >>> very vertical and monolithic VIPR proposal: the CDS straw men are = examples >>> of what one of those components would look like (roughly taking the = place >>> of the VIPR DHT). I think many of us feel that the smartphone = revolution >>> has created some new opportunities in this space that weren't around = when >>> we first started working on all this. The way the charter is = structured, >>> this out-of-band deliverable is placed after the we get done with = the >>> Identity signature revisitation, so I don't think this would be the = first >>> order of business. I do however think that we should define how that >>> system will interface with Identity, and how the credentials of the >>> systems are related (or different), and that it belongs in the scope = of >>> STIR. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From chris_wendt@cable.comcast.com Thu Jun 20 10:36: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 7A0A721F9E48 for ; Thu, 20 Jun 2013 10:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-2.767, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 PcghuypeKpKI for ; Thu, 20 Jun 2013 10:36:50 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 58E6C21F9D67 for ; Thu, 20 Jun 2013 10:36:50 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56121448; Thu, 20 Jun 2013 13:35:39 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 20 Jun 2013 13:36:40 -0400 From: "Wendt, Chris" To: Brian Rosen Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdy4YG9JHkYsaU+vynseyHv19w== Date: Thu, 20 Jun 2013 17:36:39 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD94192E84E@PACDCEXMB01.cable.comcast.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> In-Reply-To: <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: <55D966FD6F3C1A479F892C638B7F0A9F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Kyzivat Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:36:55 -0000 I personally would like to get away from user=3Dphone, but as long as there= is a authoritative domain for both TN and user based routing, I'm ok. -Chris On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: > I think Hadriel got it right - if you will route it based on the phone nu= mber, then use a phone number based identity. If you route it as a user@do= main address, then use a domain based identity. Both ends will use the sam= e assumptions or the call won't get to the intended destination. >=20 > Brian >=20 > On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: >=20 >> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>=20 >>> I don't think it matters at all whether there's a 'user=3Dphone' param = or not. Brian's right that that's what *should* be in the URI, but we all = know that isn't what happens on-the-wire. Whether there's a 'user=3Dphone'= or not, or even a leading '+' or not, if the user portion of the URI looks= like a phone number and smells like a phone number, its treated as a phone= number by virtually everyone. It's been that way for many years in SIP. >>=20 >> I have no problem with somebody using specific knowledge of how domain f= oo.example.com manages user parts to decide that the sip URI with that doma= in is a phone number, and then use the phone number to route the call. >>=20 >> But it is a serious problem if that is done *without* any knowledge of t= he target domain. Some issues with this: >> - if you route the call to the PSTN, but foo.example.com doesn't have a >> connection to receive from the PSTN, its a problem. >> - if the official mapping of the phone number part takes it to some >> other domain than foo.example.com, that's a problem. >> - if you route it to the PSTN, and it does make it back to >> foo.example.com, then it may have lost important properties, >> like video. >> - it may be that the user part only coincidentally is made up of >> digits that you happen to think look like a phone number. >>=20 >> If this is considered acceptable behavior, then we have effectively decl= ared that all user parts that even remotely resemble a phone number are res= erved, and can only be used in cases where gatewaying to PSTN is acceptable= . >>=20 >>> At a high level, it doesn't matter how something appears on-the-wire. = If the terminating domain *treats* it as a phone number, and displays to th= e user only a phone number caller-id, then we need to validate it as a phon= e number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.= com', and STIR treats it as an email-style name instead of E.164, but your = phone displays '330145295813', then foo.com will have successfully spoofed = your number. >>>=20 >>> The really important point/concept Brian made in another email thread e= arlier, I think, was the idea of determining a canonical E.164 number from = the To/From URIs. One of his points there was that sure the encoded number= in the URI may have a prefix of digits, or is missing the country-code bec= ause it's in national form, or it has visual separators in it, or whatever.= But as long as the signer and verifier can both determine what the "real"= E.164 numbers are that they need to sign/verify, then the actual user stri= ng in the URI doesn't matter. >>>=20 >>> At first I thought that idea was crazy - that it would be too hard to g= et systems along the path to be able to figure out a canonical E.164 automa= tically from random user strings they get in To/From URIs. But then I real= ized that actually it's not hard at all, and that in fact it's done all the= time. It may require more-than-trivial configuration, but ultimately ever= y carrier has to actually do that type of determination for every call that= leaves/enters their domain. Well ok, they only have to do it for internat= ional calls, but the point is a lot of them do this type of thing already. = And it's done by a lot of systems. Even SBCs do it, using number translat= ions or manipulation rules or whatever. >>>=20 >>> So if we accept the fact that the signing and verifying domains can and= will do a canonicalization step, I'd argue part of that step is deciding w= hether a received To/From URI is actually an E.164 vs. an email-style name.= It would be based on the rules of the domain, and parameters like 'user= =3Dphone' can be ignored if the domain ignores it for routing and display p= urposes anyway. >>=20 >> So as long as the part about "rules of the domain" really applies, and i= t isn't done if the rules of the domain aren't known, then I'm ok. >>=20 >> Thanks, >> Paul >>=20 >>> -hadriel >>>=20 >>>=20 >>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>=20 >>>> OK. In a Request-URI (I was thinking more of it in a From given the co= ntext) with a + sign upfront, the entities I'm familiar with would route it= based on the TN and without it, some may even also do the same. One may ar= gue that those entities are not meant to support anything else than TN-base= d sessions anyway. >>>>=20 >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Thursday, June 20, 2013 3:52 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>>=20 >>>> It's not clear to me how any downstream entity is supposed to route a = call like that. If they follow RFCs, then they would route it to example.c= om. >>>> If in fact they route it based on the +CC-YYYY e.164, then it's in sco= pe as a TN based delegation cert. >>>>=20 >>>> Brian >>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>=20 >>>>> OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@examp= le.com) Does this fall into your "based on delegation of the number" catego= ry or on the "domain entry in the DNS" one? >>>>>=20 >>>>> I guess you're going to tell me that it's a "domain based identity" w= here the user just happens to be digits :) >>>>>=20 >>>>> I'm not arguing one way or another and have some sympathy with Paul's= observation below; but I also realize as others did that we see loads of t= hem in real life (always treated as phone numbers I mean). My guess is that= in a stir environment two sip URIs sharing the same canonical form as I be= lieve those two do (with and without user=3Dphone), could be treated as the= same by the (called) endpoint though. >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf= Of Paul Kyzivat >>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>> To: stir@ietf.org >>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and oth= er middle boxes? >>>>>>=20 >>>>>=20 >>>>> [snip] >>>>>=20 >>>>>> I only bring this up because we may need to consider the implication= s of >>>>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>>>> belonging to example.com. It may be intended by example.com to repre= sent >>>>>> a phone number, but I don't think anyone without special knowledge o= f >>>>>> example.com's policies can trust that assumption. Certainly example.= com >>>>>> is free to use such a URI even if it has no rights to that phone num= ber. >>>>>=20 >>>>> [snip] >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>=20 >>>>> "domain based identities" =3D identities of the form sip:user@example= .com. >>>>> It DOES NOT include TN@example.com;user=3Dphone >>>>>=20 >>>>> Brian >>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>>=20 >>>>>> This looks good to me, thanks for summing this up. For the record, I= share the observations/reservations that have already been made on point 5= for the out-of-band mechanism and the practicalities of a gradual deployme= nt. >>>>>>=20 >>>>>> The other thing that slightly puzzles me (and that I don't quite see= in other comments) is the statement about "identities that are domain base= d" ("the credentials are based on the domain entry in the DNS "). Given tha= t the proposed charter doesn't talk about what is meant to be in scope in t= erms of URI format and what isn't, maybe this exercise will be necessary at= some point to move forward (or if this ""domain-based identity" is meant t= o clarify this, my apologies, I don't quite get it.) >>>>>>=20 >>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@doma= in.com;user=3Dphone to be validated by the endpoint, the host part must rem= ain untouched end-to-end since, if I read the above correctly, the credenti= als for +CC-XXXXXX will have to be found under domain.com (and I don't mean= this literally in the DNS). Is this correct? (incidentally to me this clea= rly restricts the use case to calling party numbers, your point 2., since f= or called parties as others have pointed out, in some networks, the host pa= rt is generally for good or bad irrelevant when the SIP URI conveys an enca= psulated tel) >>>>>>=20 >>>>>> 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 Rosen, Brian >>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Do we agree on the basics? >>>>>>=20 >>>>>> A lot of our discussion is focussed on where certs are found. I wan= t to make sure that we agree on the basics, because where certs are found i= s pretty far down the list of things to agree on. >>>>>>=20 >>>>>> So, do we agree: >>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the = SOURCE of the call, because we believe that spoofing identity or non provid= ing identity is the way the bad calls are being placed. >>>>>> 3. The METHOD we're going to use is to pick some data from the call = and sign or encrypt it in a way that a downstream entity can verify that th= e information is valid >>>>>> 4. The CREDENTIALS we're going to use, for identities that are telep= hone numbers, is based on delegation of the number, rooted in the national = numbering authority. For identities that are domain based, the credentials= are based on the domain entry in the DNS. >>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has th= e originating device or service provider signing information and carries th= e signature in the signaling. The other is some out of band mechanism that= involves some new database or service that gets written by the originating= device or service provider and checked by some downstream entity. The lat= ter mechanism is needed to allow the identity to be assured even if the inf= ormation or signature from the in band mechanism is lost (such as when the = call goes through an SS7 hop). >>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>=20 >>>>>>=20 >>>>>> That doesn't say things like where the certs are or what is signed, = or what the out of band mechanism does. >>>>>>=20 >>>>>> So, I ask, do you agree with that? >>>>>>=20 >>>>>> Brian >>>>>> _______________________________________________ >>>>>> 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 c= onfidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or privile= ged 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>>=20 >>>>> _____________________________________________________________________= ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >>>>> France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or privileg= ed 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 an= d delete this message and its attachments. >>>>> As emails may be altered, France Telecom - Orange is not liable for m= essages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>>=20 >>>> ______________________________________________________________________= ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d 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, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >>>> Thank you. >>>>=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 >>=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 Thu Jun 20 10:39: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 BB5A921F9F4F for ; Thu, 20 Jun 2013 10:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 nxJQrI581D7v for ; Thu, 20 Jun 2013 10:39:15 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2428C21F9F44 for ; Thu, 20 Jun 2013 10:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=HzAHnEmkpDU7o30g6eLetaY2ax9zXwcm1uPrqtc6JfM=; b=djJPAUgNqgOF1piY2hqOEDue/JFGBuqzN2ap63WfT5kKxDshWXxjybz4atudZLuqRu7CsK2sA/SHHzf6Jue0jLPkIXI/7QcoVAIekV0uk6kRJgBGNpbIgKKm9Ei0e1lnQZ8ounqMIEsX9ZbQSnxoE2L0dR9sulE5Tqkpnw6Kphg=; Received: from neustargw.va.neustar.com ([209.173.53.233]:29261 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UpipF-0001g6-TN; Thu, 20 Jun 2013 13:39:14 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> Date: Thu, 20 Jun 2013 13:39:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:39:19 -0000 The arguments are somewhat different depending on what the out of band = solution looks like. If it's like EKR's approach, one could argue it could be the only = mechanism.=20 If it's like my alternate SS7 GW approach, then it can't. However, the problem is that just doing something the way EKR proposes = wouldn't solve the problem until it's nearly universally deployed. That's because an intermediary can't check validity - only the end = device or service can do that. To stop the problem we're working on, we = need intermediaries to refuse calls that don't have valid identity. = It's one of my problems with that approach, although I actually like it = quite a bit. I believe in most cases you would not see P-A-I on a "pink" carrier to = "green" carrier interchange. If you did, it would be a straight copy of = what is in From. Those carriers do not police, in any way, what their = customers put on the signaling. I think that most carriers accept calls = from other carriers without PAI. We could try to change that, but then = all you would get is a copy of From. Brian On Jun 20, 2013, at 1:22 PM, Hadriel Kaplan = wrote: >=20 > OK, but my point was that view is inconsistent. The claims made are = that an out-of-band is basically a completely-overlapping superset of = the in-band: the out-of-band covers all cases, whereas the in-band does = not. The rationale for having an out-of-band is that in the near-term, = we don't have SIP everywhere, so we need the superset out-of-band = solution too. This already implies we need the out-of-band *sooner* = than we need the in-band. But more importantly if the out-of-band is = really possible, and really going to be deployed and used, then why = should we bother doing the in-band at all, ever? >=20 > Right now you're asking for the charter to cover two = mechanisms/models: an in-band and out-of-band. The claim is it's worth = our time and effort to do both, and that both have their place. I = assume the belief is both would be actually deployed and used, right? >=20 > I find it very hard to believe that. I think if we can get one = mechanism to be deployed, no one would do anything different. Why would = they?? Why should we spend the huge amount of effort it will take to do = something once, and then do it all over again a second time? >=20 > My guess is you and Jon think the problem is we need a "stop-gap" = solution that we can quickly specify and deploy, and *that's* what the = in-band is for. But that in the long term we need an out-of-band = solution, and people will switch to that because the in-band won't work = well enough in the long-term. >=20 > If that's the case, there's an existing solution we can use for a = stop-gap short-term solution: P-Asserted-Identity. No one has ever = shown me a case of P-Asserted-Identity being spoofed. It's not hard to = spoof it, obviously, because it's purely based on transitive trust. It = doesn't work through SS7, but neither would a new in-band approach.[1] = In the long-term it will likely fail, and people will be able to inject = into the trusted networks a false PAI header value that spoofs another = number. But the idea of even a new in-band solution not being good = enough in the long-term must already be believed, for us to believe = people will migrate to an out-of-band approach and make it worth our = time. >=20 > -hadriel > [1] well... we might be able to get an in-band approach to work = through short SS7 connections. Maybe. >=20 >=20 >=20 > On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: >=20 >> Because we have increasing instances of calls that don't go through = SS7 links. Most of them are effectively "on-net", or between smaller = service providers. We will have, soon enough, IMS based interchange. = We would expect services like Skype to be able to use these mechanisms. >>=20 >> Eventually, the things that are inhibiting direct SIP interconnect = will get solved. >>=20 >> It won't be a flag day, but it will happen gradually.=20 >>=20 >> The bad guys will exploit whatever holes we leave them, so we need to = cover both bases for a while. >>=20 >> EKR's idea has some longer term value. My gateway idea is just a = temporary work around for a temporary problem. >>=20 >> Brian >>=20 >> On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> Let's take a step back for a second. >>>=20 >>> You believe an out-of-band mechanism can be made to work well. You = believe that it can avoid the problems of SS7, B2BUAs, etc., in the = middle. You believe that it can and will be successfully deployed and = used, and will be deployed and useful before an in-band mechanism = already handles things sufficiently end-to-end. >>>=20 >>> So I gotta ask: why would you advocate doing an in-band approach at = all for this new WG, let alone doing it first before an out-of-band = one?? >>>=20 >>> I mean, given those beliefs for an out-of-band solution are true, = the out-of-band solution should be able to handle pure end-to-end SIP = calls too. Right? So why would the IETF ever need or want an in-band = solution? If people are going to deploy and use an out-of-band one = eventually anyway, why should they bother deploying an in-band one that = is purportedly inferior? >>>=20 >>> I mean it seems like a lot of people are going to be spending a lot = of effort on whatever we do - not just effort in the IETF writing RFCs, = but also in development, testing, documentation, training, deployment, = evangelizing, communicating with other SDOs, etc. Writing RFCs is the = easy part really. >>>=20 >>> If you feel an in-band solution is insufficient to solve the problem = at hand, then why should we spend so much effort on it if we're going to = start all over again afterwards? >>>=20 >>> If, on the other hand, doing an in-band solution is sufficient to = solve the problem at hand, why would we do something else afterwards? = For posterity? >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >>>=20 >>>>=20 >>>> I don't think anyone here is particularly interested in retreading = this >>>> debate; I think we all agree STIR would be adopting a signature = algorithm >>>> that differs from RFC4474 in a way that is intended to make it = possible >>>> for it to survive SBCs. >>>>=20 >>>> I think how I'd cast what I think Brian was getting it was more = like this: >>>> there are going to be forms of B2BUAs, like PSTN gateways, maybe = gateways >>>> associated with other standard or proprietary protocols, whatever, = that >>>> are going to effectively remove the Identity headers no matter how >>>> friendly we make them. That's just a fact of life. We want to try = to >>>> arrange things so that it won't happen as a part of ordinary SBC >>>> operation, but again, I think the problem space of robocalling = involves >>>> all kinds of use cases where SIP is only used over part of the call = path, >>>> or potentially even none of it. The secure-origins-ps draft lists = many >>>> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>>>=20 >>>> If we had some capability to let the originating and terminating = side >>>> verify, more securely than what would get from hop-by-hop trust, = that a >>>> call setup attempt from the originating number is in place, a = capability >>>> that could work around these kinds of extremely adverse B2BUA = conditions, >>>> it would help the impersonation problem. Those of us who spun our = gears on >>>> the VIPR problem for a while know that this isn't trivial, but VIPR = is at >>>> least one (implemented and even deployed, though not widely used) = example >>>> of how Internet endpoints could discover one another as endpoints = of a >>>> call and use that out-of-band connection to enhance identity and = security. >>>>=20 >>>> Clearly the knobs were not set in an ideal position for VIPR, so = what we >>>> want to explore is ways of addressing the problem space that will = be more >>>> likely to succeed. In part, that will extracting components out of = the >>>> very vertical and monolithic VIPR proposal: the CDS straw men are = examples >>>> of what one of those components would look like (roughly taking the = place >>>> of the VIPR DHT). I think many of us feel that the smartphone = revolution >>>> has created some new opportunities in this space that weren't = around when >>>> we first started working on all this. The way the charter is = structured, >>>> this out-of-band deliverable is placed after the we get done with = the >>>> Identity signature revisitation, so I don't think this would be the = first >>>> order of business. I do however think that we should define how = that >>>> system will interface with Identity, and how the credentials of the >>>> systems are related (or different), and that it belongs in the = scope of >>>> STIR. >>>>=20 >>>> Jon Peterson >>>> Neustar, Inc. >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From dhc@dcrocker.net Thu Jun 20 10:43: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 428A321F9E14 for ; Thu, 20 Jun 2013 10:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 qMSmcQBbm3h6 for ; Thu, 20 Jun 2013 10:43:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC01921F9E63 for ; Thu, 20 Jun 2013 10:43:05 -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 r5KHh13w020393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jun 2013 10:43:04 -0700 Message-ID: <51C33F13.4040901@dcrocker.net> Date: Thu, 20 Jun 2013 10:42:43 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Russ Housley References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <51C2216A.4020402@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Jun 2013 10:43:04 -0700 (PDT) Cc: stir@ietf.org Subject: [stir] Do we agree on the problem? 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, 20 Jun 2013 17:43:11 -0000 On 6/19/2013 2:41 PM, Russ Housley wrote: > BOF time should be spent making sure that there is a solution space that will lead to an interoperability specification. That is, make sure the work being considered is engineering, not research. Follow-on... To be able to debate and agree on whether the work is in engineering space, there must be agreement on the problem(s) to be solved, with enough detail to guide the engineering-vs-research analysis. The draft charter is piecemeal and generic about the problem statement. It contains quite a bit of discussion, of course, but no simple, direct, statement of the problem to be solved or the actors that will be involved in operating the solution. In fact, the current draft charter actually contains a work item to develop the problem statement. I don't understand how the BOF can agree that the working group will operate in engineering space if there is not already an agreed, basic problem statement and agreement on the broad strokes of requirements for the solution. Discussion on this list seems to move the problem statement around, in terms of the basic function(s) being sought and the actors it is intended to apply to. I suggest honing this down to a consensus statement about what is needed and for whom. Here are relevant bits of text that I've extracted from the draft charter, concerning the basic problem or the basic solution requirements, distinct from the details of how this is to be achieved: * lack of security mechanisms for attesting the origins of real-time communications * securing the origins of SIP communication * lack of any real means of asserting authority over telephone numbers on the Internet * work when one side of a call is in the PSTN – or potentially even both From the discussion on the list, I believe the basic problem statement for STIR is: Handling agents of SIP requests must be able to determine that use of a telephone number in the From field is authorized by the number's assignee. An added piece is: An authorization mechanism needs to try to be robust against transitions through SIP Border Controllers, including transit through an SS7 network. To the extent that these statements are inaccurate or incomplete, please suggest changes or replacement text. Note that these statements don't mention any of the actors who assert the authorization. I'm not sure whether that's needed, for this level of specification, but could easily imagine it is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pkyzivat@alum.mit.edu Thu Jun 20 10:45: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 8498D21F99D1 for ; Thu, 20 Jun 2013 10:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=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 LpfNrjWXThge for ; Thu, 20 Jun 2013 10:45:54 -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 C2DF721F9990 for ; Thu, 20 Jun 2013 10:45:53 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id qd6K1l0030QuhwU54hltpc; Thu, 20 Jun 2013 17:45:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id qhls1l01J3ZTu2S3NhltFq; Thu, 20 Jun 2013 17:45:53 +0000 Message-ID: <51C33FD2.5010007@alum.mit.edu> Date: Thu, 20 Jun 2013 13:45:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> In-Reply-To: <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371750353; bh=ooAozfuzoxA+nypZu5fE8yIZKZe3OsqRUKpjC7r9lfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eouotSEQhRPUlpGYlEBsQQ6H42TDNFmcO/h0qv3J6EuFmmYU/l5p3wAUBDCvyjeXY BKz7xX1JshpNRfy07djxrETlkmCxGgWIJlAZ5uOJWKd9LE1CmMgIIoLemH3Z0eCJz0 0Rd4qe1TzE1AJEU6mOwbYPS3zMS18u52SQeEGIwUKiqUWobtGXKmtRLlGcjVfuDHa9 be/Qx1eRjKXuIo8d2otTBXa4LigpeyfiTDKBsCZRMeUFXJwbFeJFqk//XRc0lEsC4E ZDWC1Lm+HOq3RrRrPCGGfTekOzYGB8aQU1kntBSY7L0Hat5/GnbnpIb9iK0wHqtWRm H0o1qybDEH6dA== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:45:58 -0000 On 6/20/13 1:17 PM, Brian Rosen wrote: > I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity. If you route it as a user@domain address, then use a domain based identity. Both ends will use the same assumptions or the call won't get to the intended destination. Yes, I agree with this. My point wasn't really a stir-specific issue. But it remains a concern. Thanks, Paul > Brian > > On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: > >> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>> >>> I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. >> >> I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call. >> >> But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this: >> - if you route the call to the PSTN, but foo.example.com doesn't have a >> connection to receive from the PSTN, its a problem. >> - if the official mapping of the phone number part takes it to some >> other domain than foo.example.com, that's a problem. >> - if you route it to the PSTN, and it does make it back to >> foo.example.com, then it may have lost important properties, >> like video. >> - it may be that the user part only coincidentally is made up of >> digits that you happen to think look like a phone number. >> >> If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable. >> >>> At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. >>> >>> The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. >>> >>> At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. >>> >>> So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. >> >> So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok. >> >> Thanks, >> Paul >> >>> -hadriel >>> >>> >>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>> >>>> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Thursday, June 20, 2013 3:52 PM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>> >>>> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >>>> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >>>> >>>> Brian >>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>> >>>>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>>>> >>>>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>>>> >>>>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>>>> >>>>>> -----Original Message----- >>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>> To: stir@ietf.org >>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>>> >>>>> >>>>> [snip] >>>>> >>>>>> I only bring this up because we may need to consider the implications of >>>>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>>>> belonging to example.com. It may be intended by example.com to represent >>>>>> a phone number, but I don't think anyone without special knowledge of >>>>>> example.com's policies can trust that assumption. Certainly example.com >>>>>> is free to use such a URI even if it has no rights to that phone number. >>>>> >>>>> [snip] >>>>> >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] Do we agree on the basics? >>>>> >>>>> "domain based identities" = identities of the form sip:user@example.com. >>>>> It DOES NOT include TN@example.com;user=phone >>>>> >>>>> Brian >>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>> >>>>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>>>> >>>>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>>>> >>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>> >>>>>> 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 Rosen, Brian >>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>> To: stir@ietf.org >>>>>> Subject: [stir] Do we agree on the basics? >>>>>> >>>>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>>>> >>>>>> So, do we agree: >>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>> >>>>>> >>>>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>>>> >>>>>> So, I ask, do you agree with that? >>>>>> >>>>>> Brian >>>>>> _______________________________________________ >>>>>> 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, >>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> 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, >>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> 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, >>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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 br@brianrosen.net Thu Jun 20 10:49: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 2D49821F9F28 for ; Thu, 20 Jun 2013 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.72 X-Spam-Level: X-Spam-Status: No, score=-99.72 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.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 4AgPYwZ9f2vO for ; Thu, 20 Jun 2013 10:49:44 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A76C721F9F77 for ; Thu, 20 Jun 2013 10:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=25vq4T5sCxM2hNZOgwA4AoFgum00gHUmxPxp705eYCg=; b=EgkdS6vzmptt3kvPNh6T2JeutNRL+TkGiaL+T4KW5JxOc2WowjAzdQBa+8LM8izPa39uSQPd89FUHU6TnIYb/JOvttdiua59qJkbXEqPM8+rwfi3hAjnmaX/ZHWgdBDEN1325iHYs4XqyiHpLxymy8acw+dvgyAlBPLv3LEKbI0=; Received: from neustargw.va.neustar.com ([209.173.53.233]:39343 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UpizN-0006Uf-2o; Thu, 20 Jun 2013 13:49:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Thu, 20 Jun 2013 13:49:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> To: Chris Wendt X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:49:48 -0000 Not sure what you mean by "get rid of user=3Dphone". A sip URI with = user=3Dphone is supposed to be directly convertible into a tel uri. Are = you arguing we should use tel uris as the only way to carry a telephone = number based address? Note that we're discussing using a canonical = e.164 as the entity we're using for the identity, so how it's encoded in = the SIP message won't matter in this work.=20 Maybe you don't get what we mean by "canonical e.164". Some examples: From: sip:202-555-1212@example.com;user=3Dphone Canonical = e.164=3D+12025551212 =46rom tel:+12025551212 Canonical e.164=3D+12025551212 From: sip:12025551212@example.com (routed as a TN) Canonical = e.164=3D+12025551212 From: sip:912025551212@example.com (in a PBX) Canonical = e.164=3D+12025551212 From: tel:8005551212 Canonical e.164=3D+18005551212 By extracting the canonical e.164, we get a string that we can do a = signature over that doesn't depend on that exact contents of =46rom = getting all the way through the network unchanged. For example, the = call could have a =46rom in the first example rewritten to the second = example by a downstream proxy, and when it gets to the endpoint, the = canonical e.164 will be the same, and therefore the signature can be = verified. Brian On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: > I personally would like to get away from user=3Dphone, but as long as = there is a authoritative domain for both TN and user based routing, I'm = ok. >=20 > -Chris >=20 > On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >=20 >> I think Hadriel got it right - if you will route it based on the = phone number, then use a phone number based identity. If you route it = as a user@domain address, then use a domain based identity. Both ends = will use the same assumptions or the call won't get to the intended = destination. >>=20 >> Brian >>=20 >> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat = wrote: >>=20 >>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>=20 >>>> I don't think it matters at all whether there's a 'user=3Dphone' = param or not. Brian's right that that's what *should* be in the URI, = but we all know that isn't what happens on-the-wire. Whether there's a = 'user=3Dphone' or not, or even a leading '+' or not, if the user portion = of the URI looks like a phone number and smells like a phone number, its = treated as a phone number by virtually everyone. It's been that way for = many years in SIP. >>>=20 >>> I have no problem with somebody using specific knowledge of how = domain foo.example.com manages user parts to decide that the sip URI = with that domain is a phone number, and then use the phone number to = route the call. >>>=20 >>> But it is a serious problem if that is done *without* any knowledge = of the target domain. Some issues with this: >>> - if you route the call to the PSTN, but foo.example.com doesn't = have a >>> connection to receive from the PSTN, its a problem. >>> - if the official mapping of the phone number part takes it to some >>> other domain than foo.example.com, that's a problem. >>> - if you route it to the PSTN, and it does make it back to >>> foo.example.com, then it may have lost important properties, >>> like video. >>> - it may be that the user part only coincidentally is made up of >>> digits that you happen to think look like a phone number. >>>=20 >>> If this is considered acceptable behavior, then we have effectively = declared that all user parts that even remotely resemble a phone number = are reserved, and can only be used in cases where gatewaying to PSTN is = acceptable. >>>=20 >>>> At a high level, it doesn't matter how something appears = on-the-wire. If the terminating domain *treats* it as a phone number, = and displays to the user only a phone number caller-id, then we need to = validate it as a phone number. Otherwise, if foo.com sends a =46rom URI = of 'sip:330145295813@foo.com', and STIR treats it as an email-style name = instead of E.164, but your phone displays '330145295813', then foo.com = will have successfully spoofed your number. >>>>=20 >>>> The really important point/concept Brian made in another email = thread earlier, I think, was the idea of determining a canonical E.164 = number from the To/=46rom URIs. One of his points there was that sure = the encoded number in the URI may have a prefix of digits, or is missing = the country-code because it's in national form, or it has visual = separators in it, or whatever. But as long as the signer and verifier = can both determine what the "real" E.164 numbers are that they need to = sign/verify, then the actual user string in the URI doesn't matter. >>>>=20 >>>> At first I thought that idea was crazy - that it would be too hard = to get systems along the path to be able to figure out a canonical E.164 = automatically from random user strings they get in To/=46rom URIs. But = then I realized that actually it's not hard at all, and that in fact = it's done all the time. It may require more-than-trivial configuration, = but ultimately every carrier has to actually do that type of = determination for every call that leaves/enters their domain. Well ok, = they only have to do it for international calls, but the point is a lot = of them do this type of thing already. And it's done by a lot of = systems. Even SBCs do it, using number translations or manipulation = rules or whatever. >>>>=20 >>>> So if we accept the fact that the signing and verifying domains can = and will do a canonicalization step, I'd argue part of that step is = deciding whether a received To/=46rom URI is actually an E.164 vs. an = email-style name. It would be based on the rules of the domain, and = parameters like 'user=3Dphone' can be ignored if the domain ignores it = for routing and display purposes anyway. >>>=20 >>> So as long as the part about "rules of the domain" really applies, = and it isn't done if the rules of the domain aren't known, then I'm ok. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>=20 >>>>> OK. In a Request-URI (I was thinking more of it in a =46rom given = the context) with a + sign upfront, the entities I'm familiar with would = route it based on the TN and without it, some may even also do the same. = One may argue that those entities are not meant to support anything else = than TN-based sessions anyway. >>>>>=20 >>>>> Philippe Fouquart >>>>> Orange Labs Networks >>>>> +33 (0) 1 45 29 58 13 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>> To: FOUQUART Philippe OLNC/OLN >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the = basics?) >>>>>=20 >>>>> It's not clear to me how any downstream entity is supposed to = route a call like that. If they follow RFCs, then they would route it = to example.com. >>>>> If in fact they route it based on the +CC-YYYY e.164, then it's in = scope as a TN based delegation cert. >>>>>=20 >>>>> Brian >>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>=20 >>>>>> OK, good, thanks. And finally what if user=3DTN? = (sip:+CC-YYYYY@example.com) Does this fall into your "based on = delegation of the number" category or on the "domain entry in the DNS" = one? >>>>>>=20 >>>>>> I guess you're going to tell me that it's a "domain based = identity" where the user just happens to be digits :) >>>>>>=20 >>>>>> I'm not arguing one way or another and have some sympathy with = Paul's observation below; but I also realize as others did that we see = loads of them in real life (always treated as phone numbers I mean). My = guess is that in a stir environment two sip URIs sharing the same = canonical form as I believe those two do (with and without user=3Dphone), = could be treated as the same by the (called) endpoint though. >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf Of Paul Kyzivat >>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>> To: stir@ietf.org >>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and = other middle boxes? >>>>>>>=20 >>>>>>=20 >>>>>> [snip] >>>>>>=20 >>>>>>> I only bring this up because we may need to consider the = implications of >>>>>>> one or the other. IMO sip:+19785551212@example.com is a private = uri >>>>>>> belonging to example.com. It may be intended by example.com to = represent >>>>>>> a phone number, but I don't think anyone without special = knowledge of >>>>>>> example.com's policies can trust that assumption. Certainly = example.com >>>>>>> is free to use such a URI even if it has no rights to that phone = number. >>>>>>=20 >>>>>> [snip] >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>=20 >>>>>> "domain based identities" =3D identities of the form = sip:user@example.com. >>>>>> It DOES NOT include TN@example.com;user=3Dphone >>>>>>=20 >>>>>> Brian >>>>>> On Jun 19, 2013, at 12:12 PM, = wrote: >>>>>>=20 >>>>>>> This looks good to me, thanks for summing this up. For the = record, I share the observations/reservations that have already been = made on point 5 for the out-of-band mechanism and the practicalities of = a gradual deployment. >>>>>>>=20 >>>>>>> The other thing that slightly puzzles me (and that I don't quite = see in other comments) is the statement about "identities that are = domain based" ("the credentials are based on the domain entry in the DNS = "). Given that the proposed charter doesn't talk about what is meant to = be in scope in terms of URI format and what isn't, maybe this exercise = will be necessary at some point to move forward (or if this = ""domain-based identity" is meant to clarify this, my apologies, I don't = quite get it.) >>>>>>>=20 >>>>>>> This assumes that for a signed and 'uncorrupted' = sip:+CC-XXXXXX@domain.com;user=3Dphone to be validated by the endpoint, = the host part must remain untouched end-to-end since, if I read the = above correctly, the credentials for +CC-XXXXXX will have to be found = under domain.com (and I don't mean this literally in the DNS). Is this = correct? (incidentally to me this clearly restricts the use case to = calling party numbers, your point 2., since for called parties as others = have pointed out, in some networks, the host part is generally for good = or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>=20 >>>>>>> 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 Rosen, Brian >>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>> To: stir@ietf.org >>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>=20 >>>>>>> A lot of our discussion is focussed on where certs are found. I = want to make sure that we agree on the basics, because where certs are = found is pretty far down the list of things to agree on. >>>>>>>=20 >>>>>>> So, do we agree: >>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and = swatting >>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of = the SOURCE of the call, because we believe that spoofing identity or non = providing identity is the way the bad calls are being placed. >>>>>>> 3. The METHOD we're going to use is to pick some data from the = call and sign or encrypt it in a way that a downstream entity can verify = that the information is valid >>>>>>> 4. The CREDENTIALS we're going to use, for identities that are = telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. >>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that = has the originating device or service provider signing information and = carries the signature in the signaling. The other is some out of band = mechanism that involves some new database or service that gets written = by the originating device or service provider and checked by some = downstream entity. The latter mechanism is needed to allow the identity = to be assured even if the information or signature from the in band = mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>=20 >>>>>>>=20 >>>>>>> That doesn't say things like where the certs are or what is = signed, or what the out of band mechanism does. >>>>>>>=20 >>>>>>> So, I ask, do you agree with that? >>>>>>>=20 >>>>>>> Brian >>>>>>> _______________________________________________ >>>>>>> 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, >>>>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>>>=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, >>>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>>=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, >>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>> Thank you. >>>>>=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 >>>=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 chris_wendt@cable.comcast.com Thu Jun 20 10:58: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 10DC021F9CCE for ; Thu, 20 Jun 2013 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.078 X-Spam-Level: X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 VtPeIHdIWnHN for ; Thu, 20 Jun 2013 10:58:43 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id C721F21F9C3B for ; Thu, 20 Jun 2013 10:58:42 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78411267; Thu, 20 Jun 2013 11:57:46 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 20 Jun 2013 13:58:27 -0400 From: "Wendt, Chris" To: Brian Rosen Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd/DYG9JHkYsaU+vynseyHv19w== Date: Thu, 20 Jun 2013 17:58:26 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> In-Reply-To: <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E79FFB48F1252489F431658F1ADD3D2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Kyzivat Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 17:58:48 -0000 No, sorry, actually the complete opposite. Depricate the use of tel uri. o= nly use SIP URI. (you quoted me wrong, didn't say get rid of, I said get a= way from) -Chris On Jun 20, 2013, at 1:49 PM, Brian Rosen wrote: > Not sure what you mean by "get rid of user=3Dphone". A sip URI with user= =3Dphone is supposed to be directly convertible into a tel uri. Are you ar= guing we should use tel uris as the only way to carry a telephone number ba= sed address? Note that we're discussing using a canonical e.164 as the ent= ity we're using for the identity, so how it's encoded in the SIP message wo= n't matter in this work.=20 >=20 > Maybe you don't get what we mean by "canonical e.164". Some examples: > From: sip:202-555-1212@example.com;user=3Dphone Canonical e.164=3D+1202= 5551212 > From tel:+12025551212 Canonical e.164=3D+12025551212 > From: sip:12025551212@example.com (routed as a TN) Canonical e.164=3D+12= 025551212 > From: sip:912025551212@example.com (in a PBX) Canonical e.164=3D+12025551= 212 > From: tel:8005551212 Canonical e.164=3D+18005551212 >=20 > By extracting the canonical e.164, we get a string that we can do a signa= ture over that doesn't depend on that exact contents of From getting all th= e way through the network unchanged. For example, the call could have a Fr= om in the first example rewritten to the second example by a downstream pro= xy, and when it gets to the endpoint, the canonical e.164 will be the same,= and therefore the signature can be verified. >=20 > Brian >=20 > On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: >=20 >> I personally would like to get away from user=3Dphone, but as long as th= ere is a authoritative domain for both TN and user based routing, I'm ok. >>=20 >> -Chris >>=20 >> On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >>=20 >>> I think Hadriel got it right - if you will route it based on the phone = number, then use a phone number based identity. If you route it as a user@= domain address, then use a domain based identity. Both ends will use the s= ame assumptions or the call won't get to the intended destination. >>>=20 >>> Brian >>>=20 >>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote= : >>>=20 >>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>>=20 >>>>> I don't think it matters at all whether there's a 'user=3Dphone' para= m or not. Brian's right that that's what *should* be in the URI, but we al= l know that isn't what happens on-the-wire. Whether there's a 'user=3Dphon= e' or not, or even a leading '+' or not, if the user portion of the URI loo= ks like a phone number and smells like a phone number, its treated as a pho= ne number by virtually everyone. It's been that way for many years in SIP. >>>>=20 >>>> I have no problem with somebody using specific knowledge of how domain= foo.example.com manages user parts to decide that the sip URI with that do= main is a phone number, and then use the phone number to route the call. >>>>=20 >>>> But it is a serious problem if that is done *without* any knowledge of= the target domain. Some issues with this: >>>> - if you route the call to the PSTN, but foo.example.com doesn't have = a >>>> connection to receive from the PSTN, its a problem. >>>> - if the official mapping of the phone number part takes it to some >>>> other domain than foo.example.com, that's a problem. >>>> - if you route it to the PSTN, and it does make it back to >>>> foo.example.com, then it may have lost important properties, >>>> like video. >>>> - it may be that the user part only coincidentally is made up of >>>> digits that you happen to think look like a phone number. >>>>=20 >>>> If this is considered acceptable behavior, then we have effectively de= clared that all user parts that even remotely resemble a phone number are r= eserved, and can only be used in cases where gatewaying to PSTN is acceptab= le. >>>>=20 >>>>> At a high level, it doesn't matter how something appears on-the-wire.= If the terminating domain *treats* it as a phone number, and displays to = the user only a phone number caller-id, then we need to validate it as a ph= one number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@fo= o.com', and STIR treats it as an email-style name instead of E.164, but you= r phone displays '330145295813', then foo.com will have successfully spoofe= d your number. >>>>>=20 >>>>> The really important point/concept Brian made in another email thread= earlier, I think, was the idea of determining a canonical E.164 number fro= m the To/From URIs. One of his points there was that sure the encoded numb= er in the URI may have a prefix of digits, or is missing the country-code b= ecause it's in national form, or it has visual separators in it, or whateve= r. But as long as the signer and verifier can both determine what the "rea= l" E.164 numbers are that they need to sign/verify, then the actual user st= ring in the URI doesn't matter. >>>>>=20 >>>>> At first I thought that idea was crazy - that it would be too hard to= get systems along the path to be able to figure out a canonical E.164 auto= matically from random user strings they get in To/From URIs. But then I re= alized that actually it's not hard at all, and that in fact it's done all t= he time. It may require more-than-trivial configuration, but ultimately ev= ery carrier has to actually do that type of determination for every call th= at leaves/enters their domain. Well ok, they only have to do it for intern= ational calls, but the point is a lot of them do this type of thing already= . And it's done by a lot of systems. Even SBCs do it, using number transl= ations or manipulation rules or whatever. >>>>>=20 >>>>> So if we accept the fact that the signing and verifying domains can a= nd will do a canonicalization step, I'd argue part of that step is deciding= whether a received To/From URI is actually an E.164 vs. an email-style nam= e. It would be based on the rules of the domain, and parameters like 'user= =3Dphone' can be ignored if the domain ignores it for routing and display p= urposes anyway. >>>>=20 >>>> So as long as the part about "rules of the domain" really applies, and= it isn't done if the rules of the domain aren't known, then I'm ok. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> -hadriel >>>>>=20 >>>>>=20 >>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>>=20 >>>>>> OK. In a Request-URI (I was thinking more of it in a From given the = context) with a + sign upfront, the entities I'm familiar with would route = it based on the TN and without it, some may even also do the same. One may = argue that those entities are not meant to support anything else than TN-ba= sed sessions anyway. >>>>>>=20 >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>>>>=20 >>>>>> It's not clear to me how any downstream entity is supposed to route = a call like that. If they follow RFCs, then they would route it to example= .com. >>>>>> If in fact they route it based on the +CC-YYYY e.164, then it's in s= cope as a TN based delegation cert. >>>>>>=20 >>>>>> Brian >>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>>=20 >>>>>>> OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@exa= mple.com) Does this fall into your "based on delegation of the number" cate= gory or on the "domain entry in the DNS" one? >>>>>>>=20 >>>>>>> I guess you're going to tell me that it's a "domain based identity"= where the user just happens to be digits :) >>>>>>>=20 >>>>>>> I'm not arguing one way or another and have some sympathy with Paul= 's observation below; but I also realize as others did that we see loads of= them in real life (always treated as phone numbers I mean). My guess is th= at in a stir environment two sip URIs sharing the same canonical form as I = believe those two do (with and without user=3Dphone), could be treated as t= he same by the (called) endpoint though. >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Beha= lf Of Paul Kyzivat >>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>> To: stir@ietf.org >>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and o= ther middle boxes? >>>>>>>>=20 >>>>>>>=20 >>>>>>> [snip] >>>>>>>=20 >>>>>>>> I only bring this up because we may need to consider the implicati= ons of >>>>>>>> one or the other. IMO sip:+19785551212@example.com is a private ur= i >>>>>>>> belonging to example.com. It may be intended by example.com to rep= resent >>>>>>>> a phone number, but I don't think anyone without special knowledge= of >>>>>>>> example.com's policies can trust that assumption. Certainly exampl= e.com >>>>>>>> is free to use such a URI even if it has no rights to that phone n= umber. >>>>>>>=20 >>>>>>> [snip] >>>>>>>=20 >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>>=20 >>>>>>> "domain based identities" =3D identities of the form sip:user@examp= le.com. >>>>>>> It DOES NOT include TN@example.com;user=3Dphone >>>>>>>=20 >>>>>>> Brian >>>>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>>>>=20 >>>>>>>> This looks good to me, thanks for summing this up. For the record,= I share the observations/reservations that have already been made on point= 5 for the out-of-band mechanism and the practicalities of a gradual deploy= ment. >>>>>>>>=20 >>>>>>>> The other thing that slightly puzzles me (and that I don't quite s= ee in other comments) is the statement about "identities that are domain ba= sed" ("the credentials are based on the domain entry in the DNS "). Given t= hat the proposed charter doesn't talk about what is meant to be in scope in= terms of URI format and what isn't, maybe this exercise will be necessary = at some point to move forward (or if this ""domain-based identity" is meant= to clarify this, my apologies, I don't quite get it.) >>>>>>>>=20 >>>>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@do= main.com;user=3Dphone to be validated by the endpoint, the host part must r= emain untouched end-to-end since, if I read the above correctly, the creden= tials for +CC-XXXXXX will have to be found under domain.com (and I don't me= an this literally in the DNS). Is this correct? (incidentally to me this cl= early restricts the use case to calling party numbers, your point 2., since= for called parties as others have pointed out, in some networks, the host = part is generally for good or bad irrelevant when the SIP URI conveys an en= capsulated tel) >>>>>>>>=20 >>>>>>>> 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 Beha= lf Of Rosen, Brian >>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>> To: stir@ietf.org >>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>>=20 >>>>>>>> A lot of our discussion is focussed on where certs are found. I w= ant to make sure that we agree on the basics, because where certs are found= is pretty far down the list of things to agree on. >>>>>>>>=20 >>>>>>>> So, do we agree: >>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of th= e SOURCE of the call, because we believe that spoofing identity or non prov= iding identity is the way the bad calls are being placed. >>>>>>>> 3. The METHOD we're going to use is to pick some data from the cal= l and sign or encrypt it in a way that a downstream entity can verify that = the information is valid >>>>>>>> 4. The CREDENTIALS we're going to use, for identities that are tel= ephone numbers, is based on delegation of the number, rooted in the nationa= l numbering authority. For identities that are domain based, the credentia= ls are based on the domain entry in the DNS. >>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has = the originating device or service provider signing information and carries = the signature in the signaling. The other is some out of band mechanism th= at involves some new database or service that gets written by the originati= ng device or service provider and checked by some downstream entity. The l= atter mechanism is needed to allow the identity to be assured even if the i= nformation or signature from the in band mechanism is lost (such as when th= e call goes through an SS7 hop). >>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> That doesn't say things like where the certs are or what is signed= , or what the out of band mechanism does. >>>>>>>>=20 >>>>>>>> So, I ask, do you agree with that? >>>>>>>>=20 >>>>>>>> Brian >>>>>>>> _______________________________________________ >>>>>>>> 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 me= ssages electroniques etant susceptibles d'alteration, >>>>>>>> France Telecom - Orange decline toute responsabilite si ce message= a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or privi= leged information that may be protected by law; >>>>>>>> they should not be distributed, used or copied without authorisati= on. >>>>>>>> If you have received this email in error, please notify the sender= and delete this message and its attachments. >>>>>>>> As emails may be altered, France Telecom - Orange is not liable fo= r messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=20 >>>>>>>=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 a= vez recu ce message par erreur, veuillez le signaler >>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration, >>>>>>> France Telecom - Orange decline toute responsabilite si ce message = a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or privil= eged information that may be protected by law; >>>>>>> they should not be distributed, used or copied without authorisatio= n. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, France Telecom - Orange is not liable for= messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>>>=20 >>>>>> ____________________________________________________________________= _____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous av= ez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les mess= ages electroniques etant susceptibles d'alteration, >>>>>> France Telecom - Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or privile= ged 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=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 >>>>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From housley@vigilsec.com Thu Jun 20 11:01: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 11D9A21F9DEB for ; Thu, 20 Jun 2013 11:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 QBpn8kXX7JaP for ; Thu, 20 Jun 2013 11:01:34 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0352221F9A34 for ; Thu, 20 Jun 2013 11:01:02 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EA93EF2407D; Thu, 20 Jun 2013 14:01:16 -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 T5gey5hFn5-d; Thu, 20 Jun 2013 14:00:08 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B6C72F24078; Thu, 20 Jun 2013 14:01:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <51C33F13.4040901@dcrocker.net> Date: Thu, 20 Jun 2013 14:00:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <51C2216A.4020402@dcrocker.net> <51C33F13.4040901@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: stir@ietf.org Subject: Re: [stir] Do we agree on the problem? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 18:01:39 -0000 The IESG has approved a meeting slot for the STIR BOF. Brian and I have been talking about the agenda, and with think that = there are three primary chunks to the agenda: problem statement, = solutions proposals, and draft charter. I think that that a charter needs to characterize the problem, and it = really needs to provide scope. However, the WG can develop a more = complete problem description as a document so long as it does not = conflict with the scope set out in the charter. Russ =3D =3D =3D =3D =3D =3D =3D =3D Problem Statement Goal: determine scope Solution Proposals Goal: demonstrate that we are ready for engineering; this is not a = research topic Draft Charter Goal: draft charter that is ready for review on the mail list and then = IESG review On Jun 20, 2013, at 1:42 PM, Dave Crocker wrote: > On 6/19/2013 2:41 PM, Russ Housley wrote: >> BOF time should be spent making sure that there is a solution space = that will lead to an interoperability specification. That is, make sure = the work being considered is engineering, not research. >=20 >=20 > Follow-on... >=20 >=20 > To be able to debate and agree on whether the work is in engineering = space, there must be agreement on the problem(s) to be solved, with = enough detail to guide the engineering-vs-research analysis. >=20 > The draft charter is piecemeal and generic about the problem = statement. It contains quite a bit of discussion, of course, but no = simple, direct, statement of the problem to be solved or the actors that = will be involved in operating the solution. >=20 > In fact, the current draft charter actually contains a work item to = develop the problem statement. I don't understand how the BOF can agree = that the working group will operate in engineering space if there is not = already an agreed, basic problem statement and agreement on the broad = strokes of requirements for the solution. >=20 > Discussion on this list seems to move the problem statement around, in = terms of the basic function(s) being sought and the actors it is = intended to apply to. I suggest honing this down to a consensus = statement about what is needed and for whom. >=20 >=20 > Here are relevant bits of text that I've extracted from the draft = charter, concerning the basic problem or the basic solution = requirements, distinct from the details of how this is to be achieved: >=20 > * lack of security mechanisms for attesting the origins of real-time > communications >=20 > * securing the origins of SIP communication >=20 > * lack of any real means of asserting authority over telephone > numbers on the Internet >=20 > * work when one side of a call is in the PSTN =96 or potentially = even > both >=20 > =46rom the discussion on the list, I believe the basic problem = statement for STIR is: >=20 > Handling agents of SIP requests must be able to determine that use > of a telephone number in the =46rom field is authorized by the > number's assignee. >=20 > An added piece is: >=20 > An authorization mechanism needs to try to be robust against > transitions through SIP Border Controllers, including transit > through an SS7 network. >=20 >=20 >=20 > To the extent that these statements are inaccurate or incomplete, = please suggest changes or replacement text. >=20 > Note that these statements don't mention any of the actors who assert = the authorization. I'm not sure whether that's needed, for this level = of specification, but could easily imagine it is. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Thu Jun 20 11:03: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 7224E21E8083 for ; Thu, 20 Jun 2013 11:03:48 -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.930, 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 dZ7eQQ-85wey for ; Thu, 20 Jun 2013 11:03:44 -0700 (PDT) Received: from GB-IP-1.fcc.gov (mail3.fcc.gov [208.31.254.166]) by ietfa.amsl.com (Postfix) with ESMTP id C556321FA000 for ; Thu, 20 Jun 2013 11:03:43 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hadriel Kaplan' , Brian Rosen Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObdrfYLU7EUyIFUCNN4IneGpC0pk+43+A Date: Thu, 20 Jun 2013 18:03:42 +0000 References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> In-Reply-To: <8CD28031-2B7D-4D0A-B299-6D1780D341BC@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" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 18:03:48 -0000 I view having multiple approaches that complement each other as insurance a= gainst our collective inability to predict deployment and non-engineering h= urdles. The approaches discussed have different trade-offs, but they don't = seem to conflict with each other. The cost to validate seems reasonably low= , in terms of implementation complexity. (The infrastructure cost is higher= , but that's where we can't really estimate with certainty what will happen= , and that may well depend on countries.) For example, some approaches are = more likely to be suitable for "self-help", informal and bottom-up deployme= nt, others probably fit better into a coordinated "formal" environment. We also seem to have champions and even proto-drafts for each, so it doesn'= t appear we'll lack for draft editors. Yes, this imposes a burden on a small segment of the industry, but mail ser= vers have learned to deal with multiple ways to do spam detection. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Thursday, June 20, 2013 1:23 PM To: Brian Rosen Cc: stir@ietf.org; Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band OK, but my point was that view is inconsistent. The claims made are that a= n out-of-band is basically a completely-overlapping superset of the in-band= : the out-of-band covers all cases, whereas the in-band does not. The rati= onale for having an out-of-band is that in the near-term, we don't have SIP= everywhere, so we need the superset out-of-band solution too. This alread= y implies we need the out-of-band *sooner* than we need the in-band. But m= ore importantly if the out-of-band is really possible, and really going to = be deployed and used, then why should we bother doing the in-band at all, e= ver? Right now you're asking for the charter to cover two mechanisms/models: an = in-band and out-of-band. The claim is it's worth our time and effort to do= both, and that both have their place. I assume the belief is both would b= e actually deployed and used, right? I find it very hard to believe that. I think if we can get one mechanism t= o be deployed, no one would do anything different. Why would they?? Why s= hould we spend the huge amount of effort it will take to do something once,= and then do it all over again a second time? My guess is you and Jon think the problem is we need a "stop-gap" solution = that we can quickly specify and deploy, and *that's* what the in-band is fo= r. But that in the long term we need an out-of-band solution, and people w= ill switch to that because the in-band won't work well enough in the long-t= erm. If that's the case, there's an existing solution we can use for a stop-gap = short-term solution: P-Asserted-Identity. No one has ever shown me a case = of P-Asserted-Identity being spoofed. It's not hard to spoof it, obviously= , because it's purely based on transitive trust. It doesn't work through S= S7, but neither would a new in-band approach.[1] In the long-term it will = likely fail, and people will be able to inject into the trusted networks a = false PAI header value that spoofs another number. But the idea of even a = new in-band solution not being good enough in the long-term must already be= believed, for us to believe people will migrate to an out-of-band approach= and make it worth our time. -hadriel [1] well... we might be able to get an in-band approach to work through sho= rt SS7 connections. Maybe. On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: > Because we have increasing instances of calls that don't go through SS7 l= inks. Most of them are effectively "on-net", or between smaller service pr= oviders. We will have, soon enough, IMS based interchange. We would expec= t services like Skype to be able to use these mechanisms. >=20 > Eventually, the things that are inhibiting direct SIP interconnect will = get solved. >=20 > It won't be a flag day, but it will happen gradually.=20 >=20 > The bad guys will exploit whatever holes we leave them, so we need to cov= er both bases for a while. >=20 > EKR's idea has some longer term value. My gateway idea is just a tempora= ry work around for a temporary problem. >=20 > Brian >=20 > On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan w= rote: >=20 >>=20 >> Let's take a step back for a second. >>=20 >> You believe an out-of-band mechanism can be made to work well. You beli= eve that it can avoid the problems of SS7, B2BUAs, etc., in the middle. Yo= u believe that it can and will be successfully deployed and used, and will = be deployed and useful before an in-band mechanism already handles things s= ufficiently end-to-end. >>=20 >> So I gotta ask: why would you advocate doing an in-band approach at all = for this new WG, let alone doing it first before an out-of-band one?? >>=20 >> I mean, given those beliefs for an out-of-band solution are true, the ou= t-of-band solution should be able to handle pure end-to-end SIP calls too. = Right? So why would the IETF ever need or want an in-band solution? If p= eople are going to deploy and use an out-of-band one eventually anyway, why= should they bother deploying an in-band one that is purportedly inferior? >>=20 >> I mean it seems like a lot of people are going to be spending a lot of e= ffort on whatever we do - not just effort in the IETF writing RFCs, but als= o in development, testing, documentation, training, deployment, evangelizin= g, communicating with other SDOs, etc. Writing RFCs is the easy part reall= y. >>=20 >> If you feel an in-band solution is insufficient to solve the problem at = hand, then why should we spend so much effort on it if we're going to start= all over again afterwards? >>=20 >> If, on the other hand, doing an in-band solution is sufficient to solve = the problem at hand, why would we do something else afterwards? For poster= ity? >>=20 >> -hadriel >>=20 >>=20 >> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >>=20 >>>=20 >>> I don't think anyone here is particularly interested in retreading=20 >>> this debate; I think we all agree STIR would be adopting a signature=20 >>> algorithm that differs from RFC4474 in a way that is intended to=20 >>> make it possible for it to survive SBCs. >>>=20 >>> I think how I'd cast what I think Brian was getting it was more like th= is: >>> there are going to be forms of B2BUAs, like PSTN gateways, maybe=20 >>> gateways associated with other standard or proprietary protocols,=20 >>> whatever, that are going to effectively remove the Identity headers=20 >>> no matter how friendly we make them. That's just a fact of life. We=20 >>> want to try to arrange things so that it won't happen as a part of=20 >>> ordinary SBC operation, but again, I think the problem space of=20 >>> robocalling involves all kinds of use cases where SIP is only used=20 >>> over part of the call path, or potentially even none of it. The=20 >>> secure-origins-ps draft lists many scenarios under consideration, inclu= ding IP-PSTN, IP-PSTN-IP, etc. >>>=20 >>> If we had some capability to let the originating and terminating=20 >>> side verify, more securely than what would get from hop-by-hop=20 >>> trust, that a call setup attempt from the originating number is in=20 >>> place, a capability that could work around these kinds of extremely=20 >>> adverse B2BUA conditions, it would help the impersonation problem.=20 >>> Those of us who spun our gears on the VIPR problem for a while know=20 >>> that this isn't trivial, but VIPR is at least one (implemented and=20 >>> even deployed, though not widely used) example of how Internet=20 >>> endpoints could discover one another as endpoints of a call and use tha= t out-of-band connection to enhance identity and security. >>>=20 >>> Clearly the knobs were not set in an ideal position for VIPR, so=20 >>> what we want to explore is ways of addressing the problem space that=20 >>> will be more likely to succeed. In part, that will extracting=20 >>> components out of the very vertical and monolithic VIPR proposal:=20 >>> the CDS straw men are examples of what one of those components would=20 >>> look like (roughly taking the place of the VIPR DHT). I think many=20 >>> of us feel that the smartphone revolution has created some new=20 >>> opportunities in this space that weren't around when we first=20 >>> started working on all this. The way the charter is structured, this=20 >>> out-of-band deliverable is placed after the we get done with the=20 >>> Identity signature revisitation, so I don't think this would be the=20 >>> first order of business. I do however think that we should define=20 >>> how that system will interface with Identity, and how the=20 >>> credentials of the systems are related (or different), and that it belo= ngs in the scope of STIR. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>=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 pp3129@att.com Thu Jun 20 12:20: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 29E1E11E80F5 for ; Thu, 20 Jun 2013 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 GmLUJDNIe9PB for ; Thu, 20 Jun 2013 12:20:08 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E421E804B for ; Thu, 20 Jun 2013 12:20:07 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 7e553c15.2aaae422c940.349582.00-575.987610.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 20 Jun 2013 19:20:07 +0000 (UTC) X-MXL-Hash: 51c355e71dff814c-bab1b62f8afafb8902780553b0c8bbd9ce0f7b29 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5e553c15.0.349568.00-404.987540.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 20 Jun 2013 19:20:07 +0000 (UTC) X-MXL-Hash: 51c355e700fb1b42-a39b9a5415630a4e9babbcdea67ccff3d0e033b3 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 r5KJK4xn023457; Thu, 20 Jun 2013 15:20:05 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5KJJuh5023370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 15:19:57 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 20 Jun 2013 19:19:44 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 15:19:51 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Hadriel Kaplan Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQrswLXXkAlPE+5zmbBJmPu15k+5uaAgAA3FYCAAASRAP//2E3w Date: Thu, 20 Jun 2013 19:19:50 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> In-Reply-To: <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> 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.20.146] X-AnalysisOut: [v=2.0 cv=R92076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=bQRfyHg_r70A:10 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8] X-AnalysisOut: [ a=HLLxP2VMAAAA:8 a=hGBaWAWWAAAA:8 a=V_Ev7mVkP-Edc3PB87YA:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [7DSvI1NPTFQA:10 a=-zy3ex45pM4A:10 a=4OXapIlvWoKrAs0W:21 a=] X-AnalysisOut: [NJnf0yVP5JRg2uQC:21] Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 19:20:20 -0000 Brian: I think we pretty much have to reject the idea that intermediaries would be= asked to refuse calls where the identity can't be validated. We could ask = it to be flagged in some fashion perhaps but I wouldn't want to kill the ca= ll. Right now US Federal regulations would prevent deletion of the CPN inf= o. 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 Bri= an Rosen Sent: Thursday, June 20, 2013 1:39 PM To: Hadriel Kaplan Cc: stir@ietf.org; Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band The arguments are somewhat different depending on what the out of band solu= tion looks like. If it's like EKR's approach, one could argue it could be the only mechanism= . If it's like my alternate SS7 GW approach, then it can't. However, the problem is that just doing something the way EKR proposes woul= dn't solve the problem until it's nearly universally deployed. That's because an intermediary can't check validity - only the end device o= r service can do that. To stop the problem we're working on, we need inter= mediaries to refuse calls that don't have valid identity. It's one of my p= roblems with that approach, although I actually like it quite a bit. I believe in most cases you would not see P-A-I on a "pink" carrier to "gre= en" carrier interchange. If you did, it would be a straight copy of what i= s in From. Those carriers do not police, in any way, what their customers = put on the signaling. I think that most carriers accept calls from other c= arriers without PAI. We could try to change that, but then all you would g= et is a copy of From. Brian On Jun 20, 2013, at 1:22 PM, Hadriel Kaplan wro= te: > > OK, but my point was that view is inconsistent. The claims made are that= an out-of-band is basically a completely-overlapping superset of the in-ba= nd: the out-of-band covers all cases, whereas the in-band does not. The ra= tionale for having an out-of-band is that in the near-term, we don't have S= IP everywhere, so we need the superset out-of-band solution too. This alre= ady implies we need the out-of-band *sooner* than we need the in-band. But= more importantly if the out-of-band is really possible, and really going t= o be deployed and used, then why should we bother doing the in-band at all,= ever? > > Right now you're asking for the charter to cover two mechanisms/models: a= n in-band and out-of-band. The claim is it's worth our time and effort to = do both, and that both have their place. I assume the belief is both would= be actually deployed and used, right? > > I find it very hard to believe that. I think if we can get one mechanism= to be deployed, no one would do anything different. Why would they?? Why= should we spend the huge amount of effort it will take to do something onc= e, and then do it all over again a second time? > > My guess is you and Jon think the problem is we need a "stop-gap" solutio= n that we can quickly specify and deploy, and *that's* what the in-band is = for. But that in the long term we need an out-of-band solution, and people= will switch to that because the in-band won't work well enough in the long= -term. > > If that's the case, there's an existing solution we can use for a stop-ga= p short-term solution: P-Asserted-Identity. No one has ever shown me a cas= e of P-Asserted-Identity being spoofed. It's not hard to spoof it, obvious= ly, because it's purely based on transitive trust. It doesn't work through= SS7, but neither would a new in-band approach.[1] In the long-term it wil= l likely fail, and people will be able to inject into the trusted networks = a false PAI header value that spoofs another number. But the idea of even = a new in-band solution not being good enough in the long-term must already = be believed, for us to believe people will migrate to an out-of-band approa= ch and make it worth our time. > > -hadriel > [1] well... we might be able to get an in-band approach to work through s= hort SS7 connections. Maybe. > > > > On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: > >> Because we have increasing instances of calls that don't go through SS7 = links. Most of them are effectively "on-net", or between smaller service p= roviders. We will have, soon enough, IMS based interchange. We would expe= ct services like Skype to be able to use these mechanisms. >> >> Eventually, the things that are inhibiting direct SIP interconnect will= get solved. >> >> It won't be a flag day, but it will happen gradually. >> >> The bad guys will exploit whatever holes we leave them, so we need to co= ver both bases for a while. >> >> EKR's idea has some longer term value. My gateway idea is just a tempor= ary work around for a temporary problem. >> >> Brian >> >> On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan = wrote: >> >>> >>> Let's take a step back for a second. >>> >>> You believe an out-of-band mechanism can be made to work well. You bel= ieve that it can avoid the problems of SS7, B2BUAs, etc., in the middle. Y= ou believe that it can and will be successfully deployed and used, and will= be deployed and useful before an in-band mechanism already handles things = sufficiently end-to-end. >>> >>> So I gotta ask: why would you advocate doing an in-band approach at all= for this new WG, let alone doing it first before an out-of-band one?? >>> >>> I mean, given those beliefs for an out-of-band solution are true, the o= ut-of-band solution should be able to handle pure end-to-end SIP calls too.= Right? So why would the IETF ever need or want an in-band solution? If = people are going to deploy and use an out-of-band one eventually anyway, wh= y should they bother deploying an in-band one that is purportedly inferior? >>> >>> I mean it seems like a lot of people are going to be spending a lot of = effort on whatever we do - not just effort in the IETF writing RFCs, but al= so in development, testing, documentation, training, deployment, evangelizi= ng, communicating with other SDOs, etc. Writing RFCs is the easy part real= ly. >>> >>> If you feel an in-band solution is insufficient to solve the problem at= hand, then why should we spend so much effort on it if we're going to star= t all over again afterwards? >>> >>> If, on the other hand, doing an in-band solution is sufficient to solve= the problem at hand, why would we do something else afterwards? For poste= rity? >>> >>> -hadriel >>> >>> >>> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >>> >>>> >>>> I don't think anyone here is particularly interested in retreading thi= s >>>> debate; I think we all agree STIR would be adopting a signature algori= thm >>>> that differs from RFC4474 in a way that is intended to make it possibl= e >>>> for it to survive SBCs. >>>> >>>> I think how I'd cast what I think Brian was getting it was more like t= his: >>>> there are going to be forms of B2BUAs, like PSTN gateways, maybe gatew= ays >>>> associated with other standard or proprietary protocols, whatever, tha= t >>>> are going to effectively remove the Identity headers no matter how >>>> friendly we make them. That's just a fact of life. We want to try to >>>> arrange things so that it won't happen as a part of ordinary SBC >>>> operation, but again, I think the problem space of robocalling involve= s >>>> all kinds of use cases where SIP is only used over part of the call pa= th, >>>> or potentially even none of it. The secure-origins-ps draft lists many >>>> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>>> >>>> If we had some capability to let the originating and terminating side >>>> verify, more securely than what would get from hop-by-hop trust, that = a >>>> call setup attempt from the originating number is in place, a capabili= ty >>>> that could work around these kinds of extremely adverse B2BUA conditio= ns, >>>> it would help the impersonation problem. Those of us who spun our gear= s on >>>> the VIPR problem for a while know that this isn't trivial, but VIPR is= at >>>> least one (implemented and even deployed, though not widely used) exam= ple >>>> of how Internet endpoints could discover one another as endpoints of a >>>> call and use that out-of-band connection to enhance identity and secur= ity. >>>> >>>> Clearly the knobs were not set in an ideal position for VIPR, so what = we >>>> want to explore is ways of addressing the problem space that will be m= ore >>>> likely to succeed. In part, that will extracting components out of the >>>> very vertical and monolithic VIPR proposal: the CDS straw men are exam= ples >>>> of what one of those components would look like (roughly taking the pl= ace >>>> of the VIPR DHT). I think many of us feel that the smartphone revoluti= on >>>> has created some new opportunities in this space that weren't around w= hen >>>> we first started working on all this. The way the charter is structure= d, >>>> this out-of-band deliverable is placed after the we get done with the >>>> Identity signature revisitation, so I don't think this would be the fi= rst >>>> order of business. I do however think that we should define how that >>>> system will interface with Identity, and how the credentials of the >>>> systems are related (or different), and that it belongs in the scope o= f >>>> STIR. >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>> >> >> _______________________________________________ >> 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 Thu Jun 20 12:29: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 46FF311E8116 for ; Thu, 20 Jun 2013 12:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 3vEspboJQ78u for ; Thu, 20 Jun 2013 12:29:08 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DC51E11E8114 for ; Thu, 20 Jun 2013 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371757035; x=1687112602; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Qwfy+I1ygE s6umlPgUJSTX3Z/FFQ8XpieiiH8g4/7Fk=; b=rB5Pvgc60ndDeobjEGKz54wp0m 1OJP6NR5h55ydg6rLNQlTDx66TuoffdBYjhLLKpwT95q9KT+YTj/9as0Y/RQ== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26619936; Thu, 20 Jun 2013 15:37:14 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 15:28:54 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aA Date: Thu, 20 Jun 2013 19:28:53 +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.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: P4s/1CI2o0GfSBv4khp5sA== Content-Type: text/plain; charset="us-ascii" Content-ID: <5E01965F0F8DB74DBB70D198984578E8@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 19:29:13 -0000 I think the in-band mechanism is going to provide better security overall than out-of-band. That's why we use terms like "fallback" for out-of-band. It's what you do as a last resort to still get some security when other avenues fail you. Jon Peterson Neustar, Inc. On 6/19/13 6:18 PM, "Hadriel Kaplan" wrote: > >Let's take a step back for a second. > >You believe an out-of-band mechanism can be made to work well. You >believe that it can avoid the problems of SS7, B2BUAs, etc., in the >middle. You believe that it can and will be successfully deployed and >used, and will be deployed and useful before an in-band mechanism already >handles things sufficiently end-to-end. > >So I gotta ask: why would you advocate doing an in-band approach at all >for this new WG, let alone doing it first before an out-of-band one?? > >I mean, given those beliefs for an out-of-band solution are true, the >out-of-band solution should be able to handle pure end-to-end SIP calls >too. Right? So why would the IETF ever need or want an in-band >solution? If people are going to deploy and use an out-of-band one >eventually anyway, why should they bother deploying an in-band one that >is purportedly inferior? > >I mean it seems like a lot of people are going to be spending a lot of >effort on whatever we do - not just effort in the IETF writing RFCs, but >also in development, testing, documentation, training, deployment, >evangelizing, communicating with other SDOs, etc. Writing RFCs is the >easy part really. > >If you feel an in-band solution is insufficient to solve the problem at >hand, then why should we spend so much effort on it if we're going to >start all over again afterwards? > >If, on the other hand, doing an in-band solution is sufficient to solve >the problem at hand, why would we do something else afterwards? For >posterity? > >-hadriel > > >On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" >wrote: > >>=20 >> I don't think anyone here is particularly interested in retreading this >> debate; I think we all agree STIR would be adopting a signature >>algorithm >> that differs from RFC4474 in a way that is intended to make it possible >> for it to survive SBCs. >>=20 >> I think how I'd cast what I think Brian was getting it was more like >>this: >> there are going to be forms of B2BUAs, like PSTN gateways, maybe >>gateways >> associated with other standard or proprietary protocols, whatever, that >> are going to effectively remove the Identity headers no matter how >> friendly we make them. That's just a fact of life. We want to try to >> arrange things so that it won't happen as a part of ordinary SBC >> operation, but again, I think the problem space of robocalling involves >> all kinds of use cases where SIP is only used over part of the call >>path, >> or potentially even none of it. The secure-origins-ps draft lists many >> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>=20 >> If we had some capability to let the originating and terminating side >> verify, more securely than what would get from hop-by-hop trust, that a >> call setup attempt from the originating number is in place, a capability >> that could work around these kinds of extremely adverse B2BUA >>conditions, >> it would help the impersonation problem. Those of us who spun our gears >>on >> the VIPR problem for a while know that this isn't trivial, but VIPR is >>at >> least one (implemented and even deployed, though not widely used) >>example >> of how Internet endpoints could discover one another as endpoints of a >> call and use that out-of-band connection to enhance identity and >>security. >>=20 >> Clearly the knobs were not set in an ideal position for VIPR, so what we >> want to explore is ways of addressing the problem space that will be >>more >> likely to succeed. In part, that will extracting components out of the >> very vertical and monolithic VIPR proposal: the CDS straw men are >>examples >> of what one of those components would look like (roughly taking the >>place >> of the VIPR DHT). I think many of us feel that the smartphone revolution >> has created some new opportunities in this space that weren't around >>when >> we first started working on all this. The way the charter is structured, >> this out-of-band deliverable is placed after the we get done with the >> Identity signature revisitation, so I don't think this would be the >>first >> order of business. I do however think that we should define how that >> system will interface with Identity, and how the credentials of the >> systems are related (or different), and that it belongs in the scope of >> STIR. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 > From dhc@dcrocker.net Thu Jun 20 12:40: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 71B6421E80C3 for ; Thu, 20 Jun 2013 12:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 rwzDkIR2EI4j for ; Thu, 20 Jun 2013 12:39:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7545721E80A8 for ; Thu, 20 Jun 2013 12:39:57 -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 r5KJdqCM023201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jun 2013 12:39:56 -0700 Message-ID: <51C35A77.5040507@dcrocker.net> Date: Thu, 20 Jun 2013 12:39:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Jun 2013 12:39:56 -0700 (PDT) Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band 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, 20 Jun 2013 19:40:02 -0000 On 6/20/2013 12:28 PM, Peterson, Jon wrote: > I think the in-band mechanism is going to provide better security overall > than out-of-band. That's why we use terms like "fallback" for out-of-band. > It's what you do as a last resort to still get some security when other > avenues fail you. Not quite. In order for it to work, the caller must employ both mechanisms, for every call. The only "fallback" is for the agent doing authorization checking. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From br@brianrosen.net Thu Jun 20 12:40: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 059B911E8122 for ; Thu, 20 Jun 2013 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.293 X-Spam-Level: X-Spam-Status: No, score=-100.293 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 OxEwwga7TMa3 for ; Thu, 20 Jun 2013 12:40:24 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F211E812B for ; Thu, 20 Jun 2013 12:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=wtXg4z5Nb8pJf8DHwcWYR0WIvf1oz/uLJrAv++vzSWA=; b=XlbxJcfqkhwRkLHbXT+dvbGXXm1ycW69XitzPJSD7Y8b8rVtGPNkHMh9CKb+AWY8BDHwPB2SkOV1gv0lGf6LLVf8s8Hzc4notDytifYO4TN7+Juhi4KyIHuDBOashKYfrqiOZQHtjfHQne7g4NWoabNZ9ZRlbVH2tLYaofMQxVk=; Received: from neustargw.va.neustar.com ([209.173.53.233]:36311 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UpkiO-0005VJ-7o; Thu, 20 Jun 2013 15:40:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Thu, 20 Jun 2013 15:40:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Hadriel Kaplan , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 19:40:29 -0000 Why is that? I understand that there are regulations that would probably prohibit = refusing calls, but we think that can and will be changed in order to = fix the problem. I don't think it works to just mark the call. You are just pushing the = problem downstream. You can't send the call to the consumer. It's not = enough to just have some flag. You probably can refuse calls that don't meet some signaling = requirements, although we understand that you have some restrictions, = Tim mentioned that. We want to get to the point where invalid or missing identity doesn't = meet your signaling requirements. It's not so much that you are = "killing calls". It's that you require valid identity from your peering = partners. You might choose to monitor identity and, at some point, = refuse to peer for example. It might have a slowly decreasing = percentage of allowable invalid/missing identity calls. Brian On Jun 20, 2013, at 3:19 PM, "PFAUTZ, PENN L" wrote: > Brian: > I think we pretty much have to reject the idea that intermediaries = would be asked to refuse calls where the identity can't be validated. We = could ask it to be flagged in some fashion perhaps but I wouldn't want = to kill the call. Right now US Federal regulations would prevent = deletion of the CPN info. >=20 > 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 Brian Rosen > Sent: Thursday, June 20, 2013 1:39 PM > To: Hadriel Kaplan > Cc: stir@ietf.org; Jon Peterson > Subject: Re: [stir] Out-of-band vs. in-band >=20 > The arguments are somewhat different depending on what the out of band = solution looks like. > If it's like EKR's approach, one could argue it could be the only = mechanism. > If it's like my alternate SS7 GW approach, then it can't. >=20 > However, the problem is that just doing something the way EKR proposes = wouldn't solve the problem until it's nearly universally deployed. > That's because an intermediary can't check validity - only the end = device or service can do that. To stop the problem we're working on, we = need intermediaries to refuse calls that don't have valid identity. = It's one of my problems with that approach, although I actually like it = quite a bit. >=20 > I believe in most cases you would not see P-A-I on a "pink" carrier to = "green" carrier interchange. If you did, it would be a straight copy of = what is in From. Those carriers do not police, in any way, what their = customers put on the signaling. I think that most carriers accept calls = from other carriers without PAI. We could try to change that, but then = all you would get is a copy of From. >=20 > Brian >=20 >=20 > On Jun 20, 2013, at 1:22 PM, Hadriel Kaplan = wrote: >=20 >>=20 >> OK, but my point was that view is inconsistent. The claims made are = that an out-of-band is basically a completely-overlapping superset of = the in-band: the out-of-band covers all cases, whereas the in-band does = not. The rationale for having an out-of-band is that in the near-term, = we don't have SIP everywhere, so we need the superset out-of-band = solution too. This already implies we need the out-of-band *sooner* = than we need the in-band. But more importantly if the out-of-band is = really possible, and really going to be deployed and used, then why = should we bother doing the in-band at all, ever? >>=20 >> Right now you're asking for the charter to cover two = mechanisms/models: an in-band and out-of-band. The claim is it's worth = our time and effort to do both, and that both have their place. I = assume the belief is both would be actually deployed and used, right? >>=20 >> I find it very hard to believe that. I think if we can get one = mechanism to be deployed, no one would do anything different. Why would = they?? Why should we spend the huge amount of effort it will take to do = something once, and then do it all over again a second time? >>=20 >> My guess is you and Jon think the problem is we need a "stop-gap" = solution that we can quickly specify and deploy, and *that's* what the = in-band is for. But that in the long term we need an out-of-band = solution, and people will switch to that because the in-band won't work = well enough in the long-term. >>=20 >> If that's the case, there's an existing solution we can use for a = stop-gap short-term solution: P-Asserted-Identity. No one has ever = shown me a case of P-Asserted-Identity being spoofed. It's not hard to = spoof it, obviously, because it's purely based on transitive trust. It = doesn't work through SS7, but neither would a new in-band approach.[1] = In the long-term it will likely fail, and people will be able to inject = into the trusted networks a false PAI header value that spoofs another = number. But the idea of even a new in-band solution not being good = enough in the long-term must already be believed, for us to believe = people will migrate to an out-of-band approach and make it worth our = time. >>=20 >> -hadriel >> [1] well... we might be able to get an in-band approach to work = through short SS7 connections. Maybe. >>=20 >>=20 >>=20 >> On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: >>=20 >>> Because we have increasing instances of calls that don't go through = SS7 links. Most of them are effectively "on-net", or between smaller = service providers. We will have, soon enough, IMS based interchange. = We would expect services like Skype to be able to use these mechanisms. >>>=20 >>> Eventually, the things that are inhibiting direct SIP interconnect = will get solved. >>>=20 >>> It won't be a flag day, but it will happen gradually. >>>=20 >>> The bad guys will exploit whatever holes we leave them, so we need = to cover both bases for a while. >>>=20 >>> EKR's idea has some longer term value. My gateway idea is just a = temporary work around for a temporary problem. >>>=20 >>> Brian >>>=20 >>> On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan = wrote: >>>=20 >>>>=20 >>>> Let's take a step back for a second. >>>>=20 >>>> You believe an out-of-band mechanism can be made to work well. You = believe that it can avoid the problems of SS7, B2BUAs, etc., in the = middle. You believe that it can and will be successfully deployed and = used, and will be deployed and useful before an in-band mechanism = already handles things sufficiently end-to-end. >>>>=20 >>>> So I gotta ask: why would you advocate doing an in-band approach at = all for this new WG, let alone doing it first before an out-of-band = one?? >>>>=20 >>>> I mean, given those beliefs for an out-of-band solution are true, = the out-of-band solution should be able to handle pure end-to-end SIP = calls too. Right? So why would the IETF ever need or want an in-band = solution? If people are going to deploy and use an out-of-band one = eventually anyway, why should they bother deploying an in-band one that = is purportedly inferior? >>>>=20 >>>> I mean it seems like a lot of people are going to be spending a lot = of effort on whatever we do - not just effort in the IETF writing RFCs, = but also in development, testing, documentation, training, deployment, = evangelizing, communicating with other SDOs, etc. Writing RFCs is the = easy part really. >>>>=20 >>>> If you feel an in-band solution is insufficient to solve the = problem at hand, then why should we spend so much effort on it if we're = going to start all over again afterwards? >>>>=20 >>>> If, on the other hand, doing an in-band solution is sufficient to = solve the problem at hand, why would we do something else afterwards? = For posterity? >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" = wrote: >>>>=20 >>>>>=20 >>>>> I don't think anyone here is particularly interested in retreading = this >>>>> debate; I think we all agree STIR would be adopting a signature = algorithm >>>>> that differs from RFC4474 in a way that is intended to make it = possible >>>>> for it to survive SBCs. >>>>>=20 >>>>> I think how I'd cast what I think Brian was getting it was more = like this: >>>>> there are going to be forms of B2BUAs, like PSTN gateways, maybe = gateways >>>>> associated with other standard or proprietary protocols, whatever, = that >>>>> are going to effectively remove the Identity headers no matter how >>>>> friendly we make them. That's just a fact of life. We want to try = to >>>>> arrange things so that it won't happen as a part of ordinary SBC >>>>> operation, but again, I think the problem space of robocalling = involves >>>>> all kinds of use cases where SIP is only used over part of the = call path, >>>>> or potentially even none of it. The secure-origins-ps draft lists = many >>>>> scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>>>>=20 >>>>> If we had some capability to let the originating and terminating = side >>>>> verify, more securely than what would get from hop-by-hop trust, = that a >>>>> call setup attempt from the originating number is in place, a = capability >>>>> that could work around these kinds of extremely adverse B2BUA = conditions, >>>>> it would help the impersonation problem. Those of us who spun our = gears on >>>>> the VIPR problem for a while know that this isn't trivial, but = VIPR is at >>>>> least one (implemented and even deployed, though not widely used) = example >>>>> of how Internet endpoints could discover one another as endpoints = of a >>>>> call and use that out-of-band connection to enhance identity and = security. >>>>>=20 >>>>> Clearly the knobs were not set in an ideal position for VIPR, so = what we >>>>> want to explore is ways of addressing the problem space that will = be more >>>>> likely to succeed. In part, that will extracting components out of = the >>>>> very vertical and monolithic VIPR proposal: the CDS straw men are = examples >>>>> of what one of those components would look like (roughly taking = the place >>>>> of the VIPR DHT). I think many of us feel that the smartphone = revolution >>>>> has created some new opportunities in this space that weren't = around when >>>>> we first started working on all this. The way the charter is = structured, >>>>> this out-of-band deliverable is placed after the we get done with = the >>>>> Identity signature revisitation, so I don't think this would be = the first >>>>> order of business. I do however think that we should define how = that >>>>> system will interface with Identity, and how the credentials of = the >>>>> systems are related (or different), and that it belongs in the = scope of >>>>> STIR. >>>>>=20 >>>>> Jon Peterson >>>>> Neustar, Inc. >>>>>=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 hadriel.kaplan@oracle.com Thu Jun 20 12: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 9CB0921F9EF9 for ; Thu, 20 Jun 2013 12:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 hsfZAbfFkH3U for ; Thu, 20 Jun 2013 12:46:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3721F9D4C for ; Thu, 20 Jun 2013 12:46:30 -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 r5KJkQ61020912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 19:46:27 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 r5KJkPrT016974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 19:46:25 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KJkPkW022302; Thu, 20 Jun 2013 19:46:25 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 12:46:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 20 Jun 2013 15:46:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Jon Peterson , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 19:46:47 -0000 On Jun 20, 2013, at 2:03 PM, Henning Schulzrinne = wrote: > I view having multiple approaches that complement each other as = insurance against our collective inability to predict deployment and = non-engineering hurdles. The approaches discussed have different = trade-offs, but they don't seem to conflict with each other. Umm... they quite clearly conflict with each other. They're two = alternative solutions to the same problem. They have different = deployment models and implementation logic. Unless you mean they don't = conflict in the sense that you could deploy both? I mean "conflict" in = the sense that they compete for the same resources: people, money, and = time. Having two solutions also makes it a lot harder to convince the = people that need to actually deploy it. How are we supposed to convince our companies, partner companies, = customers, and other SDOs to do this stuff? "Uh, well we need you all = to do X right now, but there's a Y coming later that is deployed and = managed and works differently that you'll have to do later too, because = we think this X thing we want you to do right now won't work well..." Obviously we can be wrong if we pick one solution. There're a ton of = DOA RFCs. Heck, we can pick two or three solutions and still fail. But = to start out from the outset with the goal of developing two competing = solutions generates its own set of problems. Like for example = interoperability when domain A does X and domain B does Y. Or confusion = in the marketplace. Someone from Costco once explained it quite well: = "Making people decide, that causes confusion, and they ultimately decide = to walk away." > The cost to validate seems reasonably low, in terms of implementation = complexity. (The infrastructure cost is higher, but that's where we = can't really estimate with certainty what will happen, and that may well = depend on countries.) For example, some approaches are more likely to be = suitable for "self-help", informal and bottom-up deployment, others = probably fit better into a coordinated "formal" environment. >=20 > We also seem to have champions and even proto-drafts for each, so it = doesn't appear we'll lack for draft editors. >=20 > Yes, this imposes a burden on a small segment of the industry I either agree with you, or strongly disagree - depending on how you = mean that. :) For *us*, the humans in an IETF working group, I agree it is a = relatively small burden to discuss, propose and argue over multiple = approaches to a problem in email. It's a lot more burden for us to get = them into published RFCs, but still in the grand scale of things it's a = small burden for *us* to publish RFCs for competing solutions to the = same problem. It costs us more to talk about it in IETF meetings = physically, due to the short time we get in IETF meetings for this = stuff, but yes we could afford that. Even the work required for some of = us to explain this and get this into other SDOs (and we *will* need to = do that), in the grand scale that's not a huge burden. But for the people that actually have to do the hard part: vendors to = implement it and carriers to deploy it... for them it's an *enormous* = amount of work, and a huge segment of the industry if we really want = this thing to work World-wide. And it's going to cost money. The equipment vendors may not charge = their customers more for doing two mechanisms vs. one, but it does = actually cost them more to do it. And for the carriers it also really = does cost more, because it takes more effort and resources. They have = to do more architecture planning, create more procedures, perform more = testing, do more admin work, monitor more in their NOCs, do more = training, troubleshoot more stuff, etc. Depending on the deployment = model for these STIR mechanisms, it may also cost them more to host = stuff in servers or pay third-parties to do things for them, or consume = more CPU resources on network equipment and thus cost for more = equipment. All this stuff costs real money. They even bill some of it = internally between departments. And there's no "new" money for this - this stuff doesn't create a new = revenue-generating feature, nor a feature one can use for competitive = advantage. This thing is just a cost sink: another red line item for = opex and capex, with no black line to offset it. It's got to be as = cheap as possible. And it's got to be something we think will actually = *work*. We can be wrong in the end of course, but we can't believe = we'll be wrong from the start! -hadriel From jon.peterson@neustar.biz Thu Jun 20 12:59: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 39FBB11E8105 for ; Thu, 20 Jun 2013 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Kroq9QREDUpr for ; Thu, 20 Jun 2013 12:59:28 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4EB21F9BB5 for ; Thu, 20 Jun 2013 12:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371758313; x=1687108208; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=zyssOwAjdn y1FozP3IA+6EQGCOaLDM3TMQ9wfVgz2uc=; b=lhi8Z/cycMpJq6NWTvV+JGGv5b pEsb8SolyQfyCH3VR5MUFA9qtp7T9SsqhmwxmLhZzV4U/HEaiYBhOeHpE0hw== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21233139; Thu, 20 Jun 2013 15:58:31 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 15:59:16 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgAB4WYD//5AjgA== Date: Thu, 20 Jun 2013 19:59:15 +0000 Message-ID: In-Reply-To: <51C35A77.5040507@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: MxeHgTTcSxwvFklgCogmag== Content-Type: text/plain; charset="us-ascii" Content-ID: <40A5528F4E7273439130982721B6F294@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 19:59:32 -0000 True, I've said that from start. Jon Peterson Neustar, Inc. On 6/20/13 12:39 PM, "Dave Crocker" wrote: >On 6/20/2013 12:28 PM, Peterson, Jon wrote: >> I think the in-band mechanism is going to provide better security >>overall >> than out-of-band. That's why we use terms like "fallback" for >>out-of-band. >> It's what you do as a last resort to still get some security when other >> avenues fail you. > > >Not quite. > >In order for it to work, the caller must employ both mechanisms, for >every call. > >The only "fallback" is for the agent doing authorization checking. > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From richard@shockey.us Thu Jun 20 13:03: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 C79B021F9B5C for ; Thu, 20 Jun 2013 13:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[AWL=0.354, 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 Eaa1ssaNNhgf for ; Thu, 20 Jun 2013 13:02:59 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 4B97421F9B14 for ; Thu, 20 Jun 2013 13:02:59 -0700 (PDT) Received: (qmail 9524 invoked by uid 0); 20 Jun 2013 20:02:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.unifiedlayer.com with SMTP; 20 Jun 2013 20:02: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=Y76TOslQq4Kmb2Y0lRcVxsoKz+TCFxLYS6YdG/jxwtI=; b=T4oz/gCOil4CyBR5RNJkxpyvx+6HvP+x5Y/2kNakIcXxCN7j/d2w3PvXI1JPb5GIjIGnVOU77pGkIyFeE+Ow3HD2OrJtl+8I2IGKggGSSBWCY2COHSBxbJMNcWFRGrQ+; Received: from [72.66.111.124] (port=52986 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Upl3x-0001uk-Ec; Thu, 20 Jun 2013 14:02:33 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'PFAUTZ, PENN L'" References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> In-Reply-To: <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> Date: Thu, 20 Jun 2013 16:02:31 -0400 Message-ID: <01dd01ce6df1$1a404a90$4ec0dfb0$@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: AQMJoBtfqITWkWEKhhUqIVPwmsKy6gKalVATAeMR1jYBFk7rsgDKG5t4AQ+RdiYBz4LQxpZ+tgbw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Hadriel Kaplan' , 'Jon Peterson' Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:03:04 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, June 20, 2013 3:40 PM To: PFAUTZ, PENN L Cc: stir@ietf.org; Hadriel Kaplan; Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band Why is that? I understand that there are regulations that would probably prohibit refusing calls, but we think that can and will be changed in order to fix the problem. [RS> ] WHAT! What are you thinking? You really think there would be some FCC or CRTC NPRM that would permit such behavior? What possible example could you site to come to that conclusion? Do you have any clue about the ongoing problem of rural call completion and what it has taken to even realize the problem exists much less come up with some solutions and it's not entirely clear those would work. USF/ICC reform took 10 years. Take a break and read a random selection of regulatory ex parte filings. I don't think it works to just mark the call. You are just pushing the problem downstream. You can't send the call to the consumer. It's not enough to just have some flag. You probably can refuse calls that don't meet some signaling requirements, although we understand that you have some restrictions, Tim mentioned that. [RS> ] You can probably refuse calls from carriers that don't pay their bills ..but that is another issue. We want to get to the point where invalid or missing identity doesn't meet your signaling requirements. It's not so much that you are "killing calls". It's that you require valid identity from your peering partners. You might choose to monitor identity and, at some point, refuse to peer for example. It might have a slowly decreasing percentage of allowable invalid/missing identity calls. [RS> ] The only think that a carrier can do is negotiate a voluntary bilateral interconnection agreement that states. You WILL NOT do and you MUST do and place these headers in the right order..thank you very much. Brian On Jun 20, 2013, at 3:19 PM, "PFAUTZ, PENN L" wrote: > Brian: > I think we pretty much have to reject the idea that intermediaries would be asked to refuse calls where the identity can't be validated. We could ask it to be flagged in some fashion perhaps but I wouldn't want to kill the call. Right now US Federal regulations would prevent deletion of the CPN info. > > 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 Brian Rosen > Sent: Thursday, June 20, 2013 1:39 PM > To: Hadriel Kaplan > Cc: stir@ietf.org; Jon Peterson > Subject: Re: [stir] Out-of-band vs. in-band > > The arguments are somewhat different depending on what the out of band solution looks like. > If it's like EKR's approach, one could argue it could be the only mechanism. > If it's like my alternate SS7 GW approach, then it can't. > > However, the problem is that just doing something the way EKR proposes wouldn't solve the problem until it's nearly universally deployed. > That's because an intermediary can't check validity - only the end device or service can do that. To stop the problem we're working on, we need intermediaries to refuse calls that don't have valid identity. It's one of my problems with that approach, although I actually like it quite a bit. > > I believe in most cases you would not see P-A-I on a "pink" carrier to "green" carrier interchange. If you did, it would be a straight copy of what is in From. Those carriers do not police, in any way, what their customers put on the signaling. I think that most carriers accept calls from other carriers without PAI. We could try to change that, but then all you would get is a copy of From. > > Brian > > > On Jun 20, 2013, at 1:22 PM, Hadriel Kaplan wrote: > >> >> OK, but my point was that view is inconsistent. The claims made are that an out-of-band is basically a completely-overlapping superset of the in-band: the out-of-band covers all cases, whereas the in-band does not. The rationale for having an out-of-band is that in the near-term, we don't have SIP everywhere, so we need the superset out-of-band solution too. This already implies we need the out-of-band *sooner* than we need the in-band. But more importantly if the out-of-band is really possible, and really going to be deployed and used, then why should we bother doing the in-band at all, ever? >> >> Right now you're asking for the charter to cover two mechanisms/models: an in-band and out-of-band. The claim is it's worth our time and effort to do both, and that both have their place. I assume the belief is both would be actually deployed and used, right? >> >> I find it very hard to believe that. I think if we can get one mechanism to be deployed, no one would do anything different. Why would they?? Why should we spend the huge amount of effort it will take to do something once, and then do it all over again a second time? >> >> My guess is you and Jon think the problem is we need a "stop-gap" solution that we can quickly specify and deploy, and *that's* what the in-band is for. But that in the long term we need an out-of-band solution, and people will switch to that because the in-band won't work well enough in the long-term. >> >> If that's the case, there's an existing solution we can use for a stop-gap short-term solution: P-Asserted-Identity. No one has ever shown me a case of P-Asserted-Identity being spoofed. It's not hard to spoof it, obviously, because it's purely based on transitive trust. It doesn't work through SS7, but neither would a new in-band approach.[1] In the long-term it will likely fail, and people will be able to inject into the trusted networks a false PAI header value that spoofs another number. But the idea of even a new in-band solution not being good enough in the long-term must already be believed, for us to believe people will migrate to an out-of-band approach and make it worth our time. >> >> -hadriel >> [1] well... we might be able to get an in-band approach to work through short SS7 connections. Maybe. >> >> >> >> On Jun 20, 2013, at 10:05 AM, Brian Rosen wrote: >> >>> Because we have increasing instances of calls that don't go through SS7 links. Most of them are effectively "on-net", or between smaller service providers. We will have, soon enough, IMS based interchange. We would expect services like Skype to be able to use these mechanisms. >>> >>> Eventually, the things that are inhibiting direct SIP interconnect will get solved. >>> >>> It won't be a flag day, but it will happen gradually. >>> >>> The bad guys will exploit whatever holes we leave them, so we need to cover both bases for a while. >>> >>> EKR's idea has some longer term value. My gateway idea is just a temporary work around for a temporary problem. >>> >>> Brian >>> >>> On Jun 19, 2013, at 9:18 PM, Hadriel Kaplan wrote: >>> >>>> >>>> Let's take a step back for a second. >>>> >>>> You believe an out-of-band mechanism can be made to work well. You believe that it can avoid the problems of SS7, B2BUAs, etc., in the middle. You believe that it can and will be successfully deployed and used, and will be deployed and useful before an in-band mechanism already handles things sufficiently end-to-end. >>>> >>>> So I gotta ask: why would you advocate doing an in-band approach at all for this new WG, let alone doing it first before an out-of-band one?? >>>> >>>> I mean, given those beliefs for an out-of-band solution are true, the out-of-band solution should be able to handle pure end-to-end SIP calls too. Right? So why would the IETF ever need or want an in-band solution? If people are going to deploy and use an out-of-band one eventually anyway, why should they bother deploying an in-band one that is purportedly inferior? >>>> >>>> I mean it seems like a lot of people are going to be spending a lot of effort on whatever we do - not just effort in the IETF writing RFCs, but also in development, testing, documentation, training, deployment, evangelizing, communicating with other SDOs, etc. Writing RFCs is the easy part really. >>>> >>>> If you feel an in-band solution is insufficient to solve the problem at hand, then why should we spend so much effort on it if we're going to start all over again afterwards? >>>> >>>> If, on the other hand, doing an in-band solution is sufficient to solve the problem at hand, why would we do something else afterwards? For posterity? >>>> >>>> -hadriel >>>> >>>> >>>> On Jun 19, 2013, at 5:54 PM, "Peterson, Jon" wrote: >>>> >>>>> >>>>> I don't think anyone here is particularly interested in retreading >>>>> this debate; I think we all agree STIR would be adopting a >>>>> signature algorithm that differs from RFC4474 in a way that is >>>>> intended to make it possible for it to survive SBCs. >>>>> >>>>> I think how I'd cast what I think Brian was getting it was more like this: >>>>> there are going to be forms of B2BUAs, like PSTN gateways, maybe >>>>> gateways associated with other standard or proprietary protocols, >>>>> whatever, that are going to effectively remove the Identity >>>>> headers no matter how friendly we make them. That's just a fact of >>>>> life. We want to try to arrange things so that it won't happen as >>>>> a part of ordinary SBC operation, but again, I think the problem >>>>> space of robocalling involves all kinds of use cases where SIP is >>>>> only used over part of the call path, or potentially even none of >>>>> it. The secure-origins-ps draft lists many scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc. >>>>> >>>>> If we had some capability to let the originating and terminating >>>>> side verify, more securely than what would get from hop-by-hop >>>>> trust, that a call setup attempt from the originating number is in >>>>> place, a capability that could work around these kinds of >>>>> extremely adverse B2BUA conditions, it would help the >>>>> impersonation problem. Those of us who spun our gears on the VIPR >>>>> problem for a while know that this isn't trivial, but VIPR is at >>>>> least one (implemented and even deployed, though not widely used) >>>>> example of how Internet endpoints could discover one another as endpoints of a call and use that out-of-band connection to enhance identity and security. >>>>> >>>>> Clearly the knobs were not set in an ideal position for VIPR, so >>>>> what we want to explore is ways of addressing the problem space >>>>> that will be more likely to succeed. In part, that will extracting >>>>> components out of the very vertical and monolithic VIPR proposal: >>>>> the CDS straw men are examples of what one of those components >>>>> would look like (roughly taking the place of the VIPR DHT). I >>>>> think many of us feel that the smartphone revolution has created >>>>> some new opportunities in this space that weren't around when we >>>>> first started working on all this. The way the charter is >>>>> structured, this out-of-band deliverable is placed after the we >>>>> get done with the Identity signature revisitation, so I don't >>>>> think this would be the first order of business. I do however >>>>> think that we should define how that system will interface with >>>>> Identity, and how the credentials of the systems are related (or different), and that it belongs in the scope of STIR. >>>>> >>>>> Jon Peterson >>>>> Neustar, Inc. >>>>> >>>> >>> >>> _______________________________________________ >>> 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 Thu Jun 20 13:03: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 647CE21F9BA3 for ; Thu, 20 Jun 2013 13:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 OydWflUEE0+B for ; Thu, 20 Jun 2013 13:03:10 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2421F9B29 for ; Thu, 20 Jun 2013 13:03:10 -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 r5KK36C7004182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 20:03:07 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 r5KK35p5027453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 20:03:06 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 r5KK35R7020100; Thu, 20 Jun 2013 20:03:05 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 13:03:05 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> Date: Thu, 20 Jun 2013 16:03:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "PFAUTZ, PENN L" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:03:18 -0000 On Jun 20, 2013, at 3:40 PM, Brian Rosen wrote: > Why is that? > I understand that there are regulations that would probably prohibit = refusing calls, but we think that can and will be changed in order to = fix the problem. We'd have to get to a point of virtually every carrier doing this thing, = and with virtually zero false-positives. That will take a long time. = In the meantime, we need something useful to do when we detect an = invalid or missing verification, to make it worth deploying sooner, = before we can start rejecting. Otherwise you're going to have a bunch of pissed off citizens and = corporate lobbyists. > I don't think it works to just mark the call. You are just pushing = the problem downstream. You can't send the call to the consumer. It's = not enough to just have some flag. The logical thing to do would be to change the caller-ID to the same as = when caller-id's aren't provided or are blocked: i.e, your phone = displays "unknown" or whatever it does for those situations today. = Because basically that's the case: we don't know the caller-id. When it gets more widely adopted, we could start sending invalid = caller-id calls to an announcement server telling them why they're being = blocked; or an IVR system that calls them back on the number they're = claiming; or whatever. If and when we get to a significant usage level of STIR and if it = doesn't have false-positives, we could switch to actual "rejecting". -hadriel From dhc@dcrocker.net Thu Jun 20 13:11: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 8F9D221E808A for ; Thu, 20 Jun 2013 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 0Gb8dKi-ZIXL for ; Thu, 20 Jun 2013 13:11:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD3A521E805E for ; Thu, 20 Jun 2013 13:11:24 -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 r5KKBKuF023957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jun 2013 13:11:24 -0700 Message-ID: <51C361D7.9040000@dcrocker.net> Date: Thu, 20 Jun 2013 13:11:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Jun 2013 13:11:24 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 20 Jun 2013 20:11:32 -0000 On 6/20/2013 12:59 PM, Peterson, Jon wrote: > > True, I've said that from start. "It's what you do as a last resort" means exactly the opposite from "it's done for every call". d/ > On 6/20/13 12:39 PM, "Dave Crocker" wrote: > >> On 6/20/2013 12:28 PM, Peterson, Jon wrote: >>> I think the in-band mechanism is going to provide better security >>> overall >>> than out-of-band. That's why we use terms like "fallback" for >>> out-of-band. >>> It's what you do as a last resort to still get some security when other >>> avenues fail you. >> >> >> Not quite. >> >> In order for it to work, the caller must employ both mechanisms, for >> every call. >> >> The only "fallback" is for the agent doing authorization checking. -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Thu Jun 20 13:12: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 CB70E21E80D1 for ; Thu, 20 Jun 2013 13:12:45 -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 Qh5+a65RNSmx for ; Thu, 20 Jun 2013 13:12:42 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA221E80BB for ; Thu, 20 Jun 2013 13:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371759652; x=1687112602; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=k7Gzf+hqdk bMLDZxYPC6E6hILepD6nZZzeKlyLcoRHk=; b=DmiLz7a+No61WNrmNwCD83O8Vh iHvCi1Ouzz0KMPQLUvt4PKc2TX4R0rCYcrhh/KxkK7ue3MWqubtPjRLUrFmg== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26622737; Thu, 20 Jun 2013 16:20:51 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 16:12:31 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+5ueAgAA3FICAAASRAIAAHB4AgAAFogCAAAZyAP//jUgA Date: Thu, 20 Jun 2013 20:12:30 +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.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BfpqX+BCjTPCXWaZvEP13g== Content-Type: text/plain; charset="us-ascii" Content-ID: <7FFB3B7CEE35C749A78DFE4344974D7F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:12:46 -0000 I think our job is to design a protocol that has the right hooks for policy and user interface to rely on, not to specify what those policies or user interfaces are. When calls should be rejected is a policy question, just like whether or not a phone should alert a user if the caller is anonymous. If there are desirable policies or UIs that would require different hooks than we're providing in the protocol, we should fix that. Otherwise, this isn't for us to decide here. Jon Peterson Neustar, Inc. On 6/20/13 1:03 PM, "Hadriel Kaplan" wrote: > >On Jun 20, 2013, at 3:40 PM, Brian Rosen wrote: > >> Why is that? >> I understand that there are regulations that would probably prohibit >>refusing calls, but we think that can and will be changed in order to >>fix the problem. > >We'd have to get to a point of virtually every carrier doing this thing, >and with virtually zero false-positives. That will take a long time. In >the meantime, we need something useful to do when we detect an invalid or >missing verification, to make it worth deploying sooner, before we can >start rejecting. > >Otherwise you're going to have a bunch of pissed off citizens and >corporate lobbyists. > > >> I don't think it works to just mark the call. You are just pushing the >>problem downstream. You can't send the call to the consumer. It's not >>enough to just have some flag. > >The logical thing to do would be to change the caller-ID to the same as >when caller-id's aren't provided or are blocked: i.e, your phone displays >"unknown" or whatever it does for those situations today. Because >basically that's the case: we don't know the caller-id. > >When it gets more widely adopted, we could start sending invalid >caller-id calls to an announcement server telling them why they're being >blocked; or an IVR system that calls them back on the number they're >claiming; or whatever. > >If and when we get to a significant usage level of STIR and if it doesn't >have false-positives, we could switch to actual "rejecting". > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Thu Jun 20 13:13: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 0C5C221E80D8 for ; Thu, 20 Jun 2013 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 t9CBJFU2Id5P for ; Thu, 20 Jun 2013 13:13:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1B621E80C1 for ; Thu, 20 Jun 2013 13:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371759712; x=1687112602; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=GweF+DPeMV 1T7p6hn9eXVZ2GVP7GA+hDJllJ2T/1X/g=; b=EmKdug2mkQJkWub6jN4fRI5f13 KZRxiewx1PcbAVJLnL9KJExnWPcQoznh1RXyo64Kot8vEyDJhiktlK/50WrA== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26622811; Thu, 20 Jun 2013 16:21:51 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 16:13:34 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgAB4WYD//5AjgIAAeKeA//+LVwA= Date: Thu, 20 Jun 2013 20:13:33 +0000 Message-ID: In-Reply-To: <51C361D7.9040000@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7v7MMQzWI7jCHj+/TqtoaQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <89EE9901ED049C489A907CCBCF7E2470@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:13:49 -0000 Obviously, by "you" I meant "the verification service." Jon Peterson Neustar, Inc. On 6/20/13 1:11 PM, "Dave Crocker" wrote: >On 6/20/2013 12:59 PM, Peterson, Jon wrote: >> >> True, I've said that from start. > > >"It's what you do as a last resort" means exactly the opposite from >"it's done for every call". > >d/ > > > > >> On 6/20/13 12:39 PM, "Dave Crocker" wrote: >> >>> On 6/20/2013 12:28 PM, Peterson, Jon wrote: >>>> I think the in-band mechanism is going to provide better security >>>> overall >>>> than out-of-band. That's why we use terms like "fallback" for >>>> out-of-band. >>>> It's what you do as a last resort to still get some security when >>>>other >>>> avenues fail you. >>> >>> >>> Not quite. >>> >>> In order for it to work, the caller must employ both mechanisms, for >>> every call. >>> >>> The only "fallback" is for the agent doing authorization checking. > > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From dhc@dcrocker.net Thu Jun 20 13:19: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 86E2521E80F3 for ; Thu, 20 Jun 2013 13:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 FQgN-XGHT1kY for ; Thu, 20 Jun 2013 13:19:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC421E80EA for ; Thu, 20 Jun 2013 13:19:52 -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 r5KKJkU0024105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jun 2013 13:19:50 -0700 Message-ID: <51C363D1.1000708@dcrocker.net> Date: Thu, 20 Jun 2013 13:19:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Jun 2013 13:19:50 -0700 (PDT) Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band 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, 20 Jun 2013 20:19:57 -0000 On 6/20/2013 11:03 AM, Henning Schulzrinne wrote: > I view having multiple approaches that complement each other as insurance against our collective inability to predict deployment and non-engineering hurdles. Henning, Perhaps you know of examples of a global, multi-administration infrastructure service for the Internet, that has deployed two redundant mechanisms for doing the same task and succeeded, but I don't. On the average, successful Internet services have been marked by relatively lean simplicity, not redundant, parallel functionality. Hadriel's comments about costs and incentives are worth noting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Thu Jun 20 13:32: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 A0F9A21F9D2F for ; Thu, 20 Jun 2013 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 zJTOzqbJOds9 for ; Thu, 20 Jun 2013 13:32:49 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF14F21F9D29 for ; Thu, 20 Jun 2013 13:32:48 -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 r5KKWkbJ001057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 20:32:47 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KKWjHo003359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 20:32:45 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 r5KKWi1X028514; Thu, 20 Jun 2013 20:32:44 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 13:32: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: Date: Thu, 20 Jun 2013 16:32:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B73CEFB-FEF4-4314-84DD-C70D3C62EBF0@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:32:55 -0000 On Jun 20, 2013, at 3:28 PM, "Peterson, Jon" = wrote: > I think the in-band mechanism is going to provide better security = overall > than out-of-band. That's why we use terms like "fallback" for = out-of-band. > It's what you do as a last resort to still get some security when = other > avenues fail you. Oy vey. Now we're talking about having shades of gray?? At the end of the day, some validating system has to make a choice: it's = a valid caller-id or not. They use that choice to determine whether to = accept the call, or anonymize the caller-id, or shunt it to voicemail, = or whatever. What does it mean to have "some security" vs. "better security" for = evaluating caller-id's?? I mean I understand that some security = mechanisms will have more or fewer weaknesses - but I mean what = difference will it make in the final outcome for calls, in practice? = What will the validating system do differently if it can only validate = the caller-id in the out-of-band mechanism? The system's operator has to configure it to either trust the = out-of-band caller-id, or not at all. If not, then it wouldn't even use = the out-of-band method to begin with. I assume you don't expect the verifier to note it to the human user and = let the decision to be left to the human user, do you? As you well = know, most humans can't even figure out what a simple lock-icon means on = a Web Browser, let alone if it's light green or dark green, or made of = iron vs. hardened steel. -hadriel From richard@shockey.us Thu Jun 20 13:41: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 0E05D21F938E for ; Thu, 20 Jun 2013 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.341, 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 BSr7nDHM99je for ; Thu, 20 Jun 2013 13:41:04 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 70C6E21F92BB for ; Thu, 20 Jun 2013 13:41:04 -0700 (PDT) Received: (qmail 30446 invoked by uid 0); 20 Jun 2013 20:40:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 20 Jun 2013 20:40:39 -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=Ed8ZkSQeWbv8ylx3a6aj3k1b5r+F4zsVSFj11Zzwl/M=; b=KdUgzwrGK5GwGUYM8lpqHmSX2r3D8cFNnLmlkVHOlgJtQ1gBzvOn0zHy2tyhS8RYAMufksXogQFixWfqH5oaTZBhS1NJJSKRKgu/DUSksy9HH4134SdzPkLrT9yoXdqx; Received: from [72.66.111.124] (port=53122 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uplep-0005pC-4w; Thu, 20 Jun 2013 14:40:39 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Brian Rosen'" References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <48B6306C-9AC5-470D-B877-DF475BC84600@brianrosen.net> <38726EDA2109264987B45E29E758C4D60496043A@MISOUT7MSGUSR9N.ITServices.sbc.com> <8FE33DB8-914F-4118-8E2B-0C4A0036C50C@brianrosen.net> In-Reply-To: Date: Thu, 20 Jun 2013 16:40:37 -0400 Message-ID: <01f201ce6df6$6ca13650$45e3a2f0$@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: AQMJoBtfqITWkWEKhhUqIVPwmsKy6gKalVATAeMR1jYBFk7rsgDKG5t4AQ+RdiYBz4LQxgMC/jvYlmanwYA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, "'PFAUTZ, PENN L'" , 'Jon Peterson' Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:41:10 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, June 20, 2013 4:03 PM To: Brian Rosen Cc: stir@ietf.org; PFAUTZ, PENN L; Jon Peterson Subject: Re: [stir] Out-of-band vs. in-band On Jun 20, 2013, at 3:40 PM, Brian Rosen wrote: > Why is that? > I understand that there are regulations that would probably prohibit refusing calls, but we think that can and will be changed in order to fix the problem. We'd have to get to a point of virtually every carrier doing this thing, and with virtually zero false-positives. That will take a long time. In the meantime, we need something useful to do when we detect an invalid or missing verification, to make it worth deploying sooner, before we can start rejecting. Otherwise you're going to have a bunch of pissed off citizens and corporate lobbyists. [RS> ] [RS> ] But the Federal Communications Bar Association would love it ... Humm more billable hours!! From jon.peterson@neustar.biz Thu Jun 20 13:50: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 BBE5B21F9F28 for ; Thu, 20 Jun 2013 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 podgmMpR7dol for ; Thu, 20 Jun 2013 13:49:55 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2418E21F9F23 for ; Thu, 20 Jun 2013 13:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371761887; x=1687119802; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Seph1Zs2/4 9u1S31ZJtdYLrfQMhLWR0C0K+UL3vMBAU=; b=kCiegT5VUd4YY+nk3Di8J5pEKF +JidwSIGO2FBtn4vWGIAmmczM/uNblE3fuCuCBtOW2j+6KZ4pzvrFub2jhWw== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26625999; Thu, 20 Jun 2013 16:58:06 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 16:49:50 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgA== Date: Thu, 20 Jun 2013 20:49:49 +0000 Message-ID: In-Reply-To: <6B73CEFB-FEF4-4314-84DD-C70D3C62EBF0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.220] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: F9058OWvQQWoKUUn5zHAJQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <0AB1CF12544FEB4A82CDE0699EF03FD5@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 20 Jun 2013 20:50:00 -0000 Yes, I think there can be differences in how well two mechanisms like this perform, and I don't think it's ridiculous to propose that we should use a rely on one when possible, and the other when the first isn't possible. "Better" here may mean working faster, requiring less network lookups or less crypto operations. "Better" may mean not vulnerable to certain classes of impersonation attacks that we care about, but know that we can't beat in all cases. Deployments may end up dictating what's possible. I can imagine a class of pure PSTN endpoints (a smart phone without SIP, say) that can only do out-of-band. I can imagine a class of SIP phones that can do in-band. I can imagine that when I place a call, I don't know which class of device I'm going to reach, and thus that I would want to supply both. I don't think that translates into "shades of gray" or somehow communicating that identity is semi-secure. As I said in a mail just a few minutes ago, our job here (I think) is to provide the hooks for policy and UI to plug into. I agree it's not our job to specify what color the lockbox should be. Jon Peterson Neustar, Inc. On 6/20/13 1:32 PM, "Hadriel Kaplan" wrote: > >On Jun 20, 2013, at 3:28 PM, "Peterson, Jon" >wrote: > >> I think the in-band mechanism is going to provide better security >>overall >> than out-of-band. That's why we use terms like "fallback" for >>out-of-band. >> It's what you do as a last resort to still get some security when other >> avenues fail you. > >Oy vey. Now we're talking about having shades of gray?? > >At the end of the day, some validating system has to make a choice: it's >a valid caller-id or not. They use that choice to determine whether to >accept the call, or anonymize the caller-id, or shunt it to voicemail, or >whatever. > >What does it mean to have "some security" vs. "better security" for >evaluating caller-id's?? I mean I understand that some security >mechanisms will have more or fewer weaknesses - but I mean what >difference will it make in the final outcome for calls, in practice? >What will the validating system do differently if it can only validate >the caller-id in the out-of-band mechanism? > >The system's operator has to configure it to either trust the out-of-band >caller-id, or not at all. If not, then it wouldn't even use the >out-of-band method to begin with. > >I assume you don't expect the verifier to note it to the human user and >let the decision to be left to the human user, do you? As you well know, >most humans can't even figure out what a simple lock-icon means on a Web >Browser, let alone if it's light green or dark green, or made of iron vs. >hardened steel. > >-hadriel > From hadriel.kaplan@oracle.com Fri Jun 21 02:53: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 ECA8811E817E for ; Fri, 21 Jun 2013 02:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 L05CeAnmRC3C for ; Fri, 21 Jun 2013 02:52:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88721E80CB for ; Fri, 21 Jun 2013 02:52: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 r5L9kYeW010876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 09:46:35 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 r5L9qoDR025232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 09:52:51 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 r5L9qoq4006851; Fri, 21 Jun 2013 09:52:50 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-166-188.vpn.oracle.com (/10.154.166.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 02:52:50 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 21 Jun 2013 05:52:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60661148-D09E-4156-BAC5-EECAC1F0BB9C@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 09:53:00 -0000 On Jun 20, 2013, at 4:49 PM, "Peterson, Jon" = wrote: > Yes, I think there can be differences in how well two mechanisms like = this > perform, and I don't think it's ridiculous to propose that we should = use a > rely on one when possible, and the other when the first isn't = possible. Just to be clear: it's not "ridiculous" to propose anything. I didn't = use the word "ridiculous", and I'm not trying to ridicule anyone. I'm just trying to understand why we need to have two mechanisms at all; = because I believe it's a really big deal to have to deploy two. > "Better" here may mean working faster, requiring less network lookups = or > less crypto operations. "Better" may mean not vulnerable to certain > classes of impersonation attacks that we care about, but know that we > can't beat in all cases. OK, but again what would it mean to the validation system? You've said = in-band might be more secure than out-of-band, that out-of-band may be = more susceptible to impersonation attacks. So let's say I receive an = INVITE and there's no in-band and I try the out-of-band and it tells me = the caller-id is indeed valid. Now what? You've just told me it's more = susceptible to impersonation attacks. Should I accept the INVITE? = Should I not? *Of course* one mechanism may have more or fewer weaknesses. But I = don't see why that makes any difference for why we would want two = mechanisms vs. one. Or whether one is a primary vs. fallback. Because = at the end of the day, either a mechanism is good enough to trust the = caller-id and allow the call, or it isn't. If it's too weak to trust, = then it's not usable at all even as a fallback. If it's strong enough = to trust as a fallback, then it's strong enough to be the one-and-only = mechanism. There are "no shades of gray". (btw, that's what I meant by = using that phrase in my earlier email) Unless you're thinking that the in-band will secure more than just the = caller-id? While the out-of-band only secures the caller-id?=20 -hadriel > On 6/20/13 1:32 PM, "Hadriel Kaplan" = wrote: >=20 >>=20 >> On Jun 20, 2013, at 3:28 PM, "Peterson, Jon" = >> wrote: >>=20 >>> I think the in-band mechanism is going to provide better security >>> overall >>> than out-of-band. That's why we use terms like "fallback" for >>> out-of-band. >>> It's what you do as a last resort to still get some security when = other >>> avenues fail you. >>=20 >> Oy vey. Now we're talking about having shades of gray?? >>=20 >> At the end of the day, some validating system has to make a choice: = it's >> a valid caller-id or not. They use that choice to determine whether = to >> accept the call, or anonymize the caller-id, or shunt it to = voicemail, or >> whatever. >>=20 >> What does it mean to have "some security" vs. "better security" for >> evaluating caller-id's?? I mean I understand that some security >> mechanisms will have more or fewer weaknesses - but I mean what >> difference will it make in the final outcome for calls, in practice? >> What will the validating system do differently if it can only = validate >> the caller-id in the out-of-band mechanism? >>=20 >> The system's operator has to configure it to either trust the = out-of-band >> caller-id, or not at all. If not, then it wouldn't even use the >> out-of-band method to begin with. >>=20 >> I assume you don't expect the verifier to note it to the human user = and >> let the decision to be left to the human user, do you? As you well = know, >> most humans can't even figure out what a simple lock-icon means on a = Web >> Browser, let alone if it's light green or dark green, or made of iron = vs. >> hardened steel. >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Fri Jun 21 03:04: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 0C51E21F9EF3 for ; Fri, 21 Jun 2013 03:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, 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 zeQfL63E0YmA for ; Fri, 21 Jun 2013 03:04:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE3121E80E1 for ; Fri, 21 Jun 2013 03:04:16 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 948AA22DFB2; Fri, 21 Jun 2013 12:04:15 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6C1C64C07A; Fri, 21 Jun 2013 12:04:15 +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; Fri, 21 Jun 2013 12:04:15 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTg Date: Fri, 21 Jun 2013 10:04:14 +0000 Message-ID: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" 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.5.21.113319 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 10:04:22 -0000 I guess we're saying the same thing. Maybe you're more liberal than I am an= d I'd have no problem with that :) I do understand that if originating party/signer and terminating party/veri= fier both agree on a common implicit "context" for the digit string ("the u= ser part I'll be sending is a number, no need for a user=3Dphone or a '+', = and I'll provide only the E.164 NDC-SN not the CC because my server can't d= o it and you can figure out it comes from country CC because I'll send it o= n trunk Y..."). I agree you don't need any particular syntactical elements = to flag that it's a phone number and determine its canonical form and I kno= w we sometimes have to do it for operational reasons.=20=20 I would argue, however, that outside a limited remit (eg in-net or national= calls, technical limitations of your vis-=E0-vis...), such practice doesn'= t scale well if the syntax you use is all over the place. It will generally= become an O&M nightmare if you have as many agreements of that sort as you= have interconnect bilaterals and that's why we try and stick to the identi= ty formats defined in national or international SIP "profiles". 3966 might = not be perfect in some respects but I think the principle of providing a ca= nonical form whenever applicable or a context otherwise is well-grounded. I= t sometimes require very little effort for the originating party to provide= a 'reasonably-canonical' form for what it sends and a lot more effort for = the terminating party to manage a plethora of syntax variations and double-= guess what the other guy meant (especially if you have three or four other = guys in between...).=20 Note, I'm not saying the solution that this group may come up with should p= reclude such practice (in as much as it could... indeed...) and as a matter= of fact, I would hate this since as [you and] I said, it's not an uncommon= operational practice. I'm just saying it's not something that should be re= commended or at any rate that I would recommend as "proper engineering prac= tice" (:-J) bearing in mind that there can be exceptions and we have to dea= l with those formats anyway.=20 For the record, my phone may indeed display '330145295813' if "STIR treats = it as an email-style name" but would definitely *reject* it "as an E.164" b= ecause it knows 0 is only the E.164 trunk prefix in the French dialing plan= :) (don't hate me for this, it was hard to resist) 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 Had= riel Kaplan Sent: Thursday, June 20, 2013 6:41 PM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) I don't think it matters at all whether there's a 'user=3Dphone' param or n= ot. Brian's right that that's what *should* be in the URI, but we all know= that isn't what happens on-the-wire. Whether there's a 'user=3Dphone' or = not, or even a leading '+' or not, if the user portion of the URI looks lik= e a phone number and smells like a phone number, its treated as a phone num= ber by virtually everyone. It's been that way for many years in SIP. At a high level, it doesn't matter how something appears on-the-wire. If t= he terminating domain *treats* it as a phone number, and displays to the us= er only a phone number caller-id, then we need to validate it as a phone nu= mber. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com'= , and STIR treats it as an email-style name instead of E.164, but your phon= e displays '330145295813', then foo.com will have successfully spoofed your= number. The really important point/concept Brian made in another email thread earli= er, I think, was the idea of determining a canonical E.164 number from the = To/From URIs. One of his points there was that sure the encoded number in = the URI may have a prefix of digits, or is missing the country-code because= it's in national form, or it has visual separators in it, or whatever. Bu= t as long as the signer and verifier can both determine what the "real" E.1= 64 numbers are that they need to sign/verify, then the actual user string i= n the URI doesn't matter. At first I thought that idea was crazy - that it would be too hard to get s= ystems along the path to be able to figure out a canonical E.164 automatica= lly from random user strings they get in To/From URIs. But then I realized= that actually it's not hard at all, and that in fact it's done all the tim= e. It may require more-than-trivial configuration, but ultimately every ca= rrier has to actually do that type of determination for every call that lea= ves/enters their domain. Well ok, they only have to do it for internationa= l calls, but the point is a lot of them do this type of thing already. And= it's done by a lot of systems. Even SBCs do it, using number translations= or manipulation rules or whatever. So if we accept the fact that the signing and verifying domains can and wil= l do a canonicalization step, I'd argue part of that step is deciding wheth= er a received To/From URI is actually an E.164 vs. an email-style name. It= would be based on the rules of the domain, and parameters like 'user=3Dpho= ne' can be ignored if the domain ignores it for routing and display purpose= s anyway. -hadriel On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: > OK. In a Request-URI (I was thinking more of it in a From given the conte= xt) with a + sign upfront, the entities I'm familiar with would route it ba= sed on the TN and without it, some may even also do the same. One may argue= that those entities are not meant to support anything else than TN-based s= essions anyway.=20 >=20 > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Thursday, June 20, 2013 3:52 PM > To: FOUQUART Philippe OLNC/OLN > Cc: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 > It's not clear to me how any downstream entity is supposed to route a cal= l like that. If they follow RFCs, then they would route it to example.com. > If in fact they route it based on the +CC-YYYY e.164, then it's in scope = as a TN based delegation cert. >=20 > Brian > On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >=20 >> OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@example.= com) Does this fall into your "based on delegation of the number" category = or on the "domain entry in the DNS" one? >>=20 >> I guess you're going to tell me that it's a "domain based identity" wher= e the user just happens to be digits :) >>=20 >> I'm not arguing one way or another and have some sympathy with Paul's ob= servation below; but I also realize as others did that we see loads of them= in real life (always treated as phone numbers I mean). My guess is that in= a stir environment two sip URIs sharing the same canonical form as I belie= ve those two do (with and without user=3Dphone), could be treated as the sa= me by the (called) endpoint though.=20=20=20 >>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of= Paul Kyzivat >>> Sent: Monday, June 10, 2013 10:49 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other = middle boxes? >>>=20 >>=20 >> [snip]=20 >>=20 >>> I only bring this up because we may need to consider the implications o= f=20 >>> one or the other. IMO sip:+19785551212@example.com is a private uri=20 >>> belonging to example.com. It may be intended by example.com to represen= t=20 >>> a phone number, but I don't think anyone without special knowledge of= =20 >>> example.com's policies can trust that assumption. Certainly example.com= =20 >>> is free to use such a URI even if it has no rights to that phone number. >>=20 >> [snip] >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >> Sent: Wednesday, June 19, 2013 7:24 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] Do we agree on the basics? >>=20 >> "domain based identities" =3D identities of the form sip:user@example.co= m. >> It DOES NOT include TN@example.com;user=3Dphone >>=20 >> Brian >> On Jun 19, 2013, at 12:12 PM, wrote: >>=20 >>> This looks good to me, thanks for summing this up. For the record, I sh= are the observations/reservations that have already been made on point 5 fo= r the out-of-band mechanism and the practicalities of a gradual deployment.= =20=20 >>>=20 >>> The other thing that slightly puzzles me (and that I don't quite see in= other comments) is the statement about "identities that are domain based" = ("the credentials are based on the domain entry in the DNS "). Given that t= he proposed charter doesn't talk about what is meant to be in scope in term= s of URI format and what isn't, maybe this exercise will be necessary at so= me point to move forward (or if this ""domain-based identity" is meant to c= larify this, my apologies, I don't quite get it.)=20 >>>=20 >>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.= com;user=3Dphone to be validated by the endpoint, the host part must remain= untouched end-to-end since, if I read the above correctly, the credentials= for +CC-XXXXXX will have to be found under domain.com (and I don't mean th= is literally in the DNS). Is this correct? (incidentally to me this clearly= restricts the use case to calling party numbers, your point 2., since for = called parties as others have pointed out, in some networks, the host part = is generally for good or bad irrelevant when the SIP URI conveys an encapsu= lated tel)=20 >>>=20 >>> 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= Rosen, Brian >>> Sent: Wednesday, June 19, 2013 3:52 PM >>> To: stir@ietf.org >>> Subject: [stir] Do we agree on the basics? >>>=20 >>> A lot of our discussion is focussed on where certs are found. I want t= o make sure that we agree on the basics, because where certs are found is p= retty far down the list of things to agree on. >>>=20 >>> So, do we agree: >>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOU= RCE of the call, because we believe that spoofing identity or non providing= identity is the way the bad calls are being placed. >>> 3. The METHOD we're going to use is to pick some data from the call and= sign or encrypt it in a way that a downstream entity can verify that the i= nformation is valid >>> 4. The CREDENTIALS we're going to use, for identities that are telephon= e numbers, is based on delegation of the number, rooted in the national num= bering authority. For identities that are domain based, the credentials ar= e based on the domain entry in the DNS. >>> 5. We think we need two MECHANISMS, an in-band mechanism that has the o= riginating device or service provider signing information and carries the s= ignature in the signaling. The other is some out of band mechanism that in= volves some new database or service that gets written by the originating de= vice or service provider and checked by some downstream entity. The latter= mechanism is needed to allow the identity to be assured even if the inform= ation or signature from the in band mechanism is lost (such as when the cal= l goes through an SS7 hop). >>> 6. The credentials (4) are the same in both mechanisms (5) >>>=20 >>>=20 >>> That doesn't say things like where the certs are or what is signed, or = what the out of band mechanism does. >>>=20 >>> So, I ask, do you agree with that? >>>=20 >>> Brian >>> _______________________________________________ >>> 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 conf= identielles 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 message= s electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a et= e 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, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=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 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From brian.rosen@neustar.biz Fri Jun 21 06:22: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 B732321F9FC5 for ; Fri, 21 Jun 2013 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 vOxR1A18Zxf9 for ; Fri, 21 Jun 2013 06:22:36 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id F31BF21F9A64 for ; Fri, 21 Jun 2013 06:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371820847; x=1687171402; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=FTWr5mi/1+ Kr2xCETqeWUtoM8L4Y/3vlUaymgAiXr3g=; b=pvgOZevlyR/LQcS2Q8VTmzXk1v z2vNOAaMOtB64EyfQbODLahjHsIqpf939MA6oRttcn95dpC+fzmP/tARPH1A== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19818058; Fri, 21 Jun 2013 09:20:46 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Fri, 21 Jun 2013 09:22:22 -0400 From: "Rosen, Brian" To: "philippe.fouquart@orange.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObb1Irceg+8rbrkSvrqRLwReGiJk+6X2AgAAoCYCAASNrAIAAN1qA Date: Fri, 21 Jun 2013 13:22:21 +0000 Message-ID: <58B3F4AE-26BF-4BF7-AC8F-C44B4DCBE36E@neustar.biz> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wiSGg9iGEvqNz0aIijak0w== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <420EF12BD9A1DC47BD32B9171DD4A48C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 13:22:40 -0000 For the purposes of this work, the notion is that you take the information = from From (or possibly PAI, we have to work that out), whatever it is, and = you extract the canonical e.164 from it. We may not have to send it (unles= s it's already in that form). You just extract it, and use it to compute t= he hash that is part of the signature. So, we're not proposing to change a= ny current practice. You handle calls the way you do now. Brian On Jun 21, 2013, at 6:04 AM, philippe.fouquart@orange.com wrote: > I guess we're saying the same thing. Maybe you're more liberal than I am = and I'd have no problem with that :) >=20 > I do understand that if originating party/signer and terminating party/ve= rifier both agree on a common implicit "context" for the digit string ("the= user part I'll be sending is a number, no need for a user=3Dphone or a '+'= , and I'll provide only the E.164 NDC-SN not the CC because my server can't= do it and you can figure out it comes from country CC because I'll send it= on trunk Y..."). I agree you don't need any particular syntactical element= s to flag that it's a phone number and determine its canonical form and I k= now we sometimes have to do it for operational reasons. =20 >=20 > I would argue, however, that outside a limited remit (eg in-net or nation= al calls, technical limitations of your vis-=E0-vis...), such practice does= n't scale well if the syntax you use is all over the place. It will general= ly become an O&M nightmare if you have as many agreements of that sort as y= ou have interconnect bilaterals and that's why we try and stick to the iden= tity formats defined in national or international SIP "profiles". 3966 migh= t not be perfect in some respects but I think the principle of providing a = canonical form whenever applicable or a context otherwise is well-grounded.= It sometimes require very little effort for the originating party to provi= de a 'reasonably-canonical' form for what it sends and a lot more effort fo= r the terminating party to manage a plethora of syntax variations and doubl= e-guess what the other guy meant (especially if you have three or four othe= r guys in between...).=20 >=20 > Note, I'm not saying the solution that this group may come up with should= preclude such practice (in as much as it could... indeed...) and as a matt= er of fact, I would hate this since as [you and] I said, it's not an uncomm= on operational practice. I'm just saying it's not something that should be = recommended or at any rate that I would recommend as "proper engineering pr= actice" (:-J) bearing in mind that there can be exceptions and we have to d= eal with those formats anyway.=20 >=20 > For the record, my phone may indeed display '330145295813' if "STIR treat= s it as an email-style name" but would definitely *reject* it "as an E.164"= because it knows 0 is only the E.164 trunk prefix in the French dialing pl= an :) (don't hate me for this, it was hard to resist) >=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 H= adriel Kaplan > Sent: Thursday, June 20, 2013 6:41 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 >=20 > I don't think it matters at all whether there's a 'user=3Dphone' param or= not. Brian's right that that's what *should* be in the URI, but we all kn= ow that isn't what happens on-the-wire. Whether there's a 'user=3Dphone' o= r not, or even a leading '+' or not, if the user portion of the URI looks l= ike a phone number and smells like a phone number, its treated as a phone n= umber by virtually everyone. It's been that way for many years in SIP. >=20 > At a high level, it doesn't matter how something appears on-the-wire. If= the terminating domain *treats* it as a phone number, and displays to the = user only a phone number caller-id, then we need to validate it as a phone = number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.co= m', and STIR treats it as an email-style name instead of E.164, but your ph= one displays '330145295813', then foo.com will have successfully spoofed yo= ur number. >=20 > The really important point/concept Brian made in another email thread ear= lier, I think, was the idea of determining a canonical E.164 number from th= e To/From URIs. One of his points there was that sure the encoded number i= n the URI may have a prefix of digits, or is missing the country-code becau= se it's in national form, or it has visual separators in it, or whatever. = But as long as the signer and verifier can both determine what the "real" E= .164 numbers are that they need to sign/verify, then the actual user string= in the URI doesn't matter. >=20 > At first I thought that idea was crazy - that it would be too hard to get= systems along the path to be able to figure out a canonical E.164 automati= cally from random user strings they get in To/From URIs. But then I realiz= ed that actually it's not hard at all, and that in fact it's done all the t= ime. It may require more-than-trivial configuration, but ultimately every = carrier has to actually do that type of determination for every call that l= eaves/enters their domain. Well ok, they only have to do it for internatio= nal calls, but the point is a lot of them do this type of thing already. A= nd it's done by a lot of systems. Even SBCs do it, using number translatio= ns or manipulation rules or whatever. >=20 > So if we accept the fact that the signing and verifying domains can and w= ill do a canonicalization step, I'd argue part of that step is deciding whe= ther a received To/From URI is actually an E.164 vs. an email-style name. = It would be based on the rules of the domain, and parameters like 'user=3Dp= hone' can be ignored if the domain ignores it for routing and display purpo= ses anyway. >=20 > -hadriel >=20 >=20 > On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >=20 >> OK. In a Request-URI (I was thinking more of it in a From given the cont= ext) with a + sign upfront, the entities I'm familiar with would route it b= ased on the TN and without it, some may even also do the same. One may argu= e that those entities are not meant to support anything else than TN-based = sessions anyway.=20 >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >> Sent: Thursday, June 20, 2013 3:52 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >> It's not clear to me how any downstream entity is supposed to route a ca= ll like that. If they follow RFCs, then they would route it to example.com= . >> If in fact they route it based on the +CC-YYYY e.164, then it's in scope= as a TN based delegation cert. >>=20 >> Brian >> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>=20 >>> OK, good, thanks. And finally what if user=3DTN? (sip:+CC-YYYYY@example= .com) Does this fall into your "based on delegation of the number" category= or on the "domain entry in the DNS" one? >>>=20 >>> I guess you're going to tell me that it's a "domain based identity" whe= re the user just happens to be digits :) >>>=20 >>> I'm not arguing one way or another and have some sympathy with Paul's o= bservation below; but I also realize as others did that we see loads of the= m in real life (always treated as phone numbers I mean). My guess is that i= n a stir environment two sip URIs sharing the same canonical form as I beli= eve those two do (with and without user=3Dphone), could be treated as the s= ame by the (called) endpoint though. =20 >>>=20 >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf O= f Paul Kyzivat >>>> Sent: Monday, June 10, 2013 10:49 PM >>>> To: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other= middle boxes? >>>>=20 >>>=20 >>> [snip]=20 >>>=20 >>>> I only bring this up because we may need to consider the implications = of=20 >>>> one or the other. IMO sip:+19785551212@example.com is a private uri=20 >>>> belonging to example.com. It may be intended by example.com to represe= nt=20 >>>> a phone number, but I don't think anyone without special knowledge of= =20 >>>> example.com's policies can trust that assumption. Certainly example.co= m=20 >>>> is free to use such a URI even if it has no rights to that phone numbe= r. >>>=20 >>> [snip] >>>=20 >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >>> Sent: Wednesday, June 19, 2013 7:24 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Do we agree on the basics? >>>=20 >>> "domain based identities" =3D identities of the form sip:user@example.c= om. >>> It DOES NOT include TN@example.com;user=3Dphone >>>=20 >>> Brian >>> On Jun 19, 2013, at 12:12 PM, wrote: >>>=20 >>>> This looks good to me, thanks for summing this up. For the record, I s= hare the observations/reservations that have already been made on point 5 f= or the out-of-band mechanism and the practicalities of a gradual deployment= . =20 >>>>=20 >>>> The other thing that slightly puzzles me (and that I don't quite see i= n other comments) is the statement about "identities that are domain based"= ("the credentials are based on the domain entry in the DNS "). Given that = the proposed charter doesn't talk about what is meant to be in scope in ter= ms of URI format and what isn't, maybe this exercise will be necessary at s= ome point to move forward (or if this ""domain-based identity" is meant to = clarify this, my apologies, I don't quite get it.)=20 >>>>=20 >>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain= .com;user=3Dphone to be validated by the endpoint, the host part must remai= n untouched end-to-end since, if I read the above correctly, the credential= s for +CC-XXXXXX will have to be found under domain.com (and I don't mean t= his literally in the DNS). Is this correct? (incidentally to me this clearl= y restricts the use case to calling party numbers, your point 2., since for= called parties as others have pointed out, in some networks, the host part= is generally for good or bad irrelevant when the SIP URI conveys an encaps= ulated tel)=20 >>>>=20 >>>> 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 O= f Rosen, Brian >>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Do we agree on the basics? >>>>=20 >>>> A lot of our discussion is focussed on where certs are found. I want = to make sure that we agree on the basics, because where certs are found is = pretty far down the list of things to agree on. >>>>=20 >>>> So, do we agree: >>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SO= URCE of the call, because we believe that spoofing identity or non providin= g identity is the way the bad calls are being placed. >>>> 3. The METHOD we're going to use is to pick some data from the call an= d sign or encrypt it in a way that a downstream entity can verify that the = information is valid >>>> 4. The CREDENTIALS we're going to use, for identities that are telepho= ne numbers, is based on delegation of the number, rooted in the national nu= mbering authority. For identities that are domain based, the credentials a= re based on the domain entry in the DNS. >>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the = originating device or service provider signing information and carries the = signature in the signaling. The other is some out of band mechanism that i= nvolves some new database or service that gets written by the originating d= evice or service provider and checked by some downstream entity. The latte= r mechanism is needed to allow the identity to be assured even if the infor= mation or signature from the in band mechanism is lost (such as when the ca= ll goes through an SS7 hop). >>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>=20 >>>>=20 >>>> That doesn't say things like where the certs are or what is signed, or= what the out of band mechanism does. >>>>=20 >>>> So, I ask, do you agree with that? >>>>=20 >>>> Brian >>>> _______________________________________________ >>>> 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 con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d 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, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles 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 message= s electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a et= e 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, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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, >> France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >>=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 > _________________________________________________________________________= ________________________________________________ >=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, > France Telecom - 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 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From hadriel.kaplan@oracle.com Fri Jun 21 10:53: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 7BD9F21F9E76 for ; Fri, 21 Jun 2013 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_45=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 MhLzDI6YyiPe for ; Fri, 21 Jun 2013 10:53:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DD23D21F9C16 for ; Fri, 21 Jun 2013 10:53:02 -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 r5LHr1kl001580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 17:53:02 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 r5LHr03W014966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 17:53:01 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LHr0uq009155; Fri, 21 Jun 2013 17:53:00 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 10:53:00 -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: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Fri, 21 Jun 2013 13:52:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 17:53:09 -0000 On Jun 21, 2013, at 6:04 AM, philippe.fouquart@orange.com wrote: > I do understand that if originating party/signer and terminating = party/verifier both agree on a common implicit "context" for the digit = string ("the user part I'll be sending is a number, no need for a = user=3Dphone or a '+', and I'll provide only the E.164 NDC-SN not the CC = because my server can't do it and you can figure out it comes from = country CC because I'll send it on trunk Y..."). I agree you don't need = any particular syntactical elements to flag that it's a phone number and = determine its canonical form and I know we sometimes have to do it for = operational reasons. =20 >=20 > I would argue, however, that outside a limited remit (eg in-net or = national calls, technical limitations of your vis-=E0-vis...), such = practice doesn't scale well if the syntax you use is all over the place. = It will generally become an O&M nightmare if you have as many agreements = of that sort as you have interconnect bilaterals and that's why we try = and stick to the identity formats defined in national or international = SIP "profiles". 3966 might not be perfect in some respects but I think = the principle of providing a canonical form whenever applicable or a = context otherwise is well-grounded. It sometimes require very little = effort for the originating party to provide a 'reasonably-canonical' = form for what it sends and a lot more effort for the terminating party = to manage a plethora of syntax variations and double-guess what the = other guy meant (especially if you have three or four other guys in = between...).=20 Just to be clear: I'm not suggesting anything change in the = To/From/req-uri/etc. at all - they are whatever they are today, for you, = in your network/systems. If you ran wireshark, you'd see no difference. = (well... other than there's a new "Identity" header or whatever) Whether we have to get pre-agreement between the originator/signer and = the terminator/verifier on this canonicalization is a critical subject - = my *hope*, is that we can do it without needing any such agreement, = because having to do that would basically kill the entire idea. I'm half-way done with a draft proposing a new Identity header thing, = that includes how the canonicalization works (or not). I hope to get = the draft submitted soon. I was writing up a bigger draft on a way to = replace all of 4474, using the DNS approach for holding certs, mostly to = see if DNS would make sense for it or not, but that draft will take = longer so I split out just the parts about a new header and signature. > For the record, my phone may indeed display '330145295813' if "STIR = treats it as an email-style name" but would definitely *reject* it "as = an E.164" because it knows 0 is only the E.164 trunk prefix in the = French dialing plan :) (don't hate me for this, it was hard to resist) Hah! Ya know, I was actually considering looking online to see if the = trunk prefix was part of the number or not before I sent the email, = because every time I call Europe I get confused about whether to dial = the '0' or not, and I *always* choose incorrectly. So this time I = thought to myself: "every time you chose before you get it wrong, and = the obvious thing is the zero is not included, so the obvious thing must = be wrong because you got it wrong every other time before, so clearly = the zero *is* included." And apparently I think that way every time. :( -hadriel From york@isoc.org Fri Jun 21 10:54: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 96B8121F9FE4 for ; Fri, 21 Jun 2013 10:54:45 -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, 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 3akZqRW1X96j for ; Fri, 21 Jun 2013 10:54:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E521F9E76 for ; Fri, 21 Jun 2013 10:54:41 -0700 (PDT) Received: from BN1PR06MB072.namprd06.prod.outlook.com (10.242.211.17) by BN1PR06MB071.namprd06.prod.outlook.com (10.242.211.15) with Microsoft SMTP Server (TLS) id 15.0.702.21; Fri, 21 Jun 2013 17:54:37 +0000 Received: from BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.133]) by BN1PR06MB072.namprd06.prod.outlook.com ([169.254.5.155]) with mapi id 15.00.0702.005; Fri, 21 Jun 2013 17:54:37 +0000 From: Dan York To: "stir@ietf.org" Thread-Topic: ITU blog: Countering The Upsurge In Numbering Fraud Thread-Index: AQHObqhkcZWZYxlyHEmK6rAaZIbsUQ== Date: Fri, 21 Jun 2013 17:54:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.5] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR06MB071; H:BN1PR06MB072.namprd06.prod.outlook.com; LANG:en; Content-Type: multipart/alternative; boundary="_000_CDEA0B9AEF91yorkisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: [stir] ITU blog: Countering The Upsurge In Numbering Fraud X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 17:54:45 -0000 --_000_CDEA0B9AEF91yorkisocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Going back to Brian's definition of WHY we need secure origin identificati= on in IP communications, we've been talking mostly of the FCC's concerns ar= ound robocalling, phishing, etc., but other countries are voicing similar c= oncerns - and here is an ITU blog post out today on the general topic: http://itu4u.wordpress.com/2013/06/21/countering-the-upsurge-in-numbering-f= raud/ Note: "at a recent ITU workshop on origin identification and alternative ca= lling procedures, Ghana indicated that studies had found about 25% of the c= ountry=92s incoming traffic to be affected by SIM-box fraud and the suppres= sion or spoofing of CLI (Calling Line Identification)." Dan P.S. And yes, I do realize that the ITU blog post also gets into other bigg= er call routing issues that would not necessarily be solved by the issues t= hat we are working on here. --_000_CDEA0B9AEF91yorkisocorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0127F2A3D76BA6479EE9E35DA252E688@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Going back to  Brian's definition of WHY we need secure origin id= entification in IP communications, we've been talking mostly of the FCC's c= oncerns around robocalling, phishing, etc., but other countries are voicing= similar concerns - and here is an ITU blog post out today on the general topic:


Note: "at a recent ITU workshop on origin identification and alte= rnative calling procedures, Ghana indicated that studies had found about 25= % of the country=92s incoming traffic to be affected by SIM-box fraud and t= he suppression or spoofing of CLI (Calling Line Identification)."

Dan

P.S. And yes, I do realize that the ITU blog post also gets into other= bigger call routing issues that would not necessarily be solved by the iss= ues that we are working on here. 


--_000_CDEA0B9AEF91yorkisocorg_-- From pkyzivat@alum.mit.edu Fri Jun 21 11:25: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 08F1311E81AA for ; Fri, 21 Jun 2013 11:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 XRi6HAu50Wqu for ; Fri, 21 Jun 2013 11:25:20 -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 E6A7611E8104 for ; Fri, 21 Jun 2013 11:25:13 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id qz0A1l0041vXlb85F6RBJe; Fri, 21 Jun 2013 18:25:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id r6RB1l0033ZTu2S3d6RBHq; Fri, 21 Jun 2013 18:25:11 +0000 Message-ID: <51C49A86.7070106@alum.mit.edu> Date: Fri, 21 Jun 2013 14:25:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Rosen References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> In-Reply-To: <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371839111; bh=SS4L2X6SfSZCVezIKJIei9cLGNhoXtnHpQLEAiqnayI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DsFrIdxT8eX+M7cRz+SPH2Y9E4FJxaxFdOYi46bn/trl00gQA5RIUJQ753tde2hMV FZ1NIRmyDH9ZlQJgdT8OAVEK3qe049vcx7x/9WeI9vG7ou09dvSuNUzbgNknHXJqqj FCh07BsdmAgas0YX84zyTaEp6w5sW85hMqnCPd7FiEPvtPKUxhtSSZ8kkhqzBlZ9xG uHNxA2zd8/qhnp0HjM3bxLzZPnzb4rL8/7h5mNaGYL6L3V4pW5D+nQCcVyXDrLPr92 l2/yOxjzNXY6n0xhwD9PdLZ8Us6sYIpWu7s/fUJlcmx+9de13r78He4/kN1YWOVo8e JU9LA/HVk4RAg== Cc: stir@ietf.org, Chris Wendt Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 18:25:25 -0000 On 6/20/13 1:49 PM, Brian Rosen wrote: > Not sure what you mean by "get rid of user=phone". A sip URI with user=phone is supposed to be directly convertible into a tel uri. By my reading of 3261, you are stretching the definition of user=phone. 3261 says: The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. The above is unfortunately limited in many respects: - it *doesn't* say "if the user string is *not* formatted as a telephone-subscriber then the user parameter value "phone" MUST NOT be present." But even so, I read between the lines and conclude that this is intended. So IMO is a non-conforming usage. - it most definitely doesn't say "if user=phone is present you may ignore the domain when routing the request." If a sip URI with user=phone were converted to a tel: uri then that would result in ignoring the domain when routing. - I find the last sentence significant, because it talks about local restrictions on the namespace. Local to whom? IMO the only thing that makes sense is "if restrictions by the domain on the namespace for user name allow it." And that means you can't infer this unless you are *aware* of the namespace policies for the domain. Thanks, Paul > Are you arguing we should use tel uris as the only way to carry a telephone number based address? Note that we're discussing using a canonical e.164 as the entity we're using for the identity, so how it's encoded in the SIP message won't matter in this work. > > Maybe you don't get what we mean by "canonical e.164". Some examples: > From: sip:202-555-1212@example.com;user=phone Canonical e.164=+12025551212 > From tel:+12025551212 Canonical e.164=+12025551212 > From: sip:12025551212@example.com (routed as a TN) Canonical e.164=+12025551212 > From: sip:912025551212@example.com (in a PBX) Canonical e.164=+12025551212 > From: tel:8005551212 Canonical e.164=+18005551212 > > By extracting the canonical e.164, we get a string that we can do a signature over that doesn't depend on that exact contents of From getting all the way through the network unchanged. For example, the call could have a From in the first example rewritten to the second example by a downstream proxy, and when it gets to the endpoint, the canonical e.164 will be the same, and therefore the signature can be verified. > > Brian > > On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: > >> I personally would like to get away from user=phone, but as long as there is a authoritative domain for both TN and user based routing, I'm ok. >> >> -Chris >> >> On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >> >>> I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity. If you route it as a user@domain address, then use a domain based identity. Both ends will use the same assumptions or the call won't get to the intended destination. >>> >>> Brian >>> >>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: >>> >>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>> >>>>> I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. >>>> >>>> I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call. >>>> >>>> But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this: >>>> - if you route the call to the PSTN, but foo.example.com doesn't have a >>>> connection to receive from the PSTN, its a problem. >>>> - if the official mapping of the phone number part takes it to some >>>> other domain than foo.example.com, that's a problem. >>>> - if you route it to the PSTN, and it does make it back to >>>> foo.example.com, then it may have lost important properties, >>>> like video. >>>> - it may be that the user part only coincidentally is made up of >>>> digits that you happen to think look like a phone number. >>>> >>>> If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable. >>>> >>>>> At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. >>>>> >>>>> The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. >>>>> >>>>> At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. >>>>> >>>>> So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. >>>> >>>> So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>> >>>>>> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >>>>>> >>>>>> Philippe Fouquart >>>>>> Orange Labs Networks >>>>>> +33 (0) 1 45 29 58 13 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>>>> >>>>>> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >>>>>> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >>>>>> >>>>>> Brian >>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>> >>>>>>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>>>>>> >>>>>>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>>>>>> >>>>>>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>> To: stir@ietf.org >>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>>> I only bring this up because we may need to consider the implications of >>>>>>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>>>>>> belonging to example.com. It may be intended by example.com to represent >>>>>>>> a phone number, but I don't think anyone without special knowledge of >>>>>>>> example.com's policies can trust that assumption. Certainly example.com >>>>>>>> is free to use such a URI even if it has no rights to that phone number. >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>> >>>>>>> "domain based identities" = identities of the form sip:user@example.com. >>>>>>> It DOES NOT include TN@example.com;user=phone >>>>>>> >>>>>>> Brian >>>>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>>>> >>>>>>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>>>>>> >>>>>>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>>>>>> >>>>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>> >>>>>>>> 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 Rosen, Brian >>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>> To: stir@ietf.org >>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>> >>>>>>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>>>>>> >>>>>>>> So, do we agree: >>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>>>>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>>>>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>> >>>>>>>> >>>>>>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>>>>>> >>>>>>>> So, I ask, do you agree with that? >>>>>>>> >>>>>>>> Brian >>>>>>>> _______________________________________________ >>>>>>>> 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, >>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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, >>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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, >>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 br@brianrosen.net Fri Jun 21 11:51: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 6C34421F9FB3 for ; Fri, 21 Jun 2013 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.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 5BtgHwhLOn1e for ; Fri, 21 Jun 2013 11:51:06 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2A04821F9F78 for ; Fri, 21 Jun 2013 11:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=MEcsbEKvhv9pmQJLUGqzn6viqIK476pu4bCkpL8o1sM=; b=bfBmN4y1bMxmdAqiguFahPLbowUKTg7axRV96EvC48ytEh6TSBrgivOSR9kqb6eAlAIuMNoRAInWx4Y+Qh0dpR+IF3xsclzIUXCkKwMQfue4q49JmkmMbci5XAz5pGFXhv+uC45FWrcKdRWk80Vp81BLmV5raEsQDom9Q8bFvUM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:26873 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uq6QC-0000ig-SH; Fri, 21 Jun 2013 14:50:57 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51C49A86.7070106@alum.mit.edu> Date: Fri, 21 Jun 2013 14:50:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97455285-D366-415A-8A29-4DC6760505CD@brianrosen.net> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <51C49A86.7070106@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Chris Wendt Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 18:51:10 -0000 Yeah, I stretched, sorry. I think the bottom line hasn't changed. The originator can determine = what the telephone number of the termination is. It can take whatever = URI is provided, and turn it into an e.164. Right now, I think we can = ignore calls within a domain where there may not be an e.164 (such as = within a PBX without DIDs for each extension). Brian On Jun 21, 2013, at 2:25 PM, Paul Kyzivat wrote: > On 6/20/13 1:49 PM, Brian Rosen wrote: >> Not sure what you mean by "get rid of user=3Dphone". A sip URI with = user=3Dphone is supposed to be directly convertible into a tel uri. >=20 > By my reading of 3261, you are stretching the definition of = user=3Dphone. 3261 says: >=20 > The set of valid telephone-subscriber strings is a subset of > valid user strings. The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. If the user string contains a > telephone number formatted as a telephone-subscriber, the user > parameter value "phone" SHOULD be present. Even without this > parameter, recipients of SIP and SIPS URIs MAY interpret the > pre-@ part as a telephone number if local restrictions on the > name space for user name allow it. >=20 > The above is unfortunately limited in many respects: >=20 > - it *doesn't* say "if the user string is *not* formatted as a > telephone-subscriber then the user parameter value "phone" MUST NOT > be present." But even so, I read between the lines and conclude that > this is intended. So IMO > is a non-conforming usage. >=20 > - it most definitely doesn't say "if user=3Dphone is present you may > ignore the domain when routing the request." If a sip URI with > user=3Dphone were converted to a tel: uri then that would result > in ignoring the domain when routing. >=20 > - I find the last sentence significant, because it talks about local > restrictions on the namespace. Local to whom? IMO the only thing > that makes sense is "if restrictions by the domain on the namespace > for user name allow it." And that means you can't infer this > unless you are *aware* of the namespace policies for the domain. >=20 > Thanks, > Paul >=20 >> Are you arguing we should use tel uris as the only way to carry a = telephone number based address? Note that we're discussing using a = canonical e.164 as the entity we're using for the identity, so how it's = encoded in the SIP message won't matter in this work. >>=20 >> Maybe you don't get what we mean by "canonical e.164". Some = examples: >> From: sip:202-555-1212@example.com;user=3Dphone Canonical = e.164=3D+12025551212 >> =46rom tel:+12025551212 Canonical e.164=3D+12025551212 >> From: sip:12025551212@example.com (routed as a TN) Canonical = e.164=3D+12025551212 >> From: sip:912025551212@example.com (in a PBX) Canonical = e.164=3D+12025551212 >> From: tel:8005551212 Canonical e.164=3D+18005551212 >>=20 >> By extracting the canonical e.164, we get a string that we can do a = signature over that doesn't depend on that exact contents of =46rom = getting all the way through the network unchanged. For example, the = call could have a =46rom in the first example rewritten to the second = example by a downstream proxy, and when it gets to the endpoint, the = canonical e.164 will be the same, and therefore the signature can be = verified. >>=20 >> Brian >>=20 >> On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: >>=20 >>> I personally would like to get away from user=3Dphone, but as long = as there is a authoritative domain for both TN and user based routing, = I'm ok. >>>=20 >>> -Chris >>>=20 >>> On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >>>=20 >>>> I think Hadriel got it right - if you will route it based on the = phone number, then use a phone number based identity. If you route it = as a user@domain address, then use a domain based identity. Both ends = will use the same assumptions or the call won't get to the intended = destination. >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat = wrote: >>>>=20 >>>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>>>=20 >>>>>> I don't think it matters at all whether there's a 'user=3Dphone' = param or not. Brian's right that that's what *should* be in the URI, = but we all know that isn't what happens on-the-wire. Whether there's a = 'user=3Dphone' or not, or even a leading '+' or not, if the user portion = of the URI looks like a phone number and smells like a phone number, its = treated as a phone number by virtually everyone. It's been that way for = many years in SIP. >>>>>=20 >>>>> I have no problem with somebody using specific knowledge of how = domain foo.example.com manages user parts to decide that the sip URI = with that domain is a phone number, and then use the phone number to = route the call. >>>>>=20 >>>>> But it is a serious problem if that is done *without* any = knowledge of the target domain. Some issues with this: >>>>> - if you route the call to the PSTN, but foo.example.com doesn't = have a >>>>> connection to receive from the PSTN, its a problem. >>>>> - if the official mapping of the phone number part takes it to = some >>>>> other domain than foo.example.com, that's a problem. >>>>> - if you route it to the PSTN, and it does make it back to >>>>> foo.example.com, then it may have lost important properties, >>>>> like video. >>>>> - it may be that the user part only coincidentally is made up of >>>>> digits that you happen to think look like a phone number. >>>>>=20 >>>>> If this is considered acceptable behavior, then we have = effectively declared that all user parts that even remotely resemble a = phone number are reserved, and can only be used in cases where = gatewaying to PSTN is acceptable. >>>>>=20 >>>>>> At a high level, it doesn't matter how something appears = on-the-wire. If the terminating domain *treats* it as a phone number, = and displays to the user only a phone number caller-id, then we need to = validate it as a phone number. Otherwise, if foo.com sends a =46rom URI = of 'sip:330145295813@foo.com', and STIR treats it as an email-style name = instead of E.164, but your phone displays '330145295813', then foo.com = will have successfully spoofed your number. >>>>>>=20 >>>>>> The really important point/concept Brian made in another email = thread earlier, I think, was the idea of determining a canonical E.164 = number from the To/=46rom URIs. One of his points there was that sure = the encoded number in the URI may have a prefix of digits, or is missing = the country-code because it's in national form, or it has visual = separators in it, or whatever. But as long as the signer and verifier = can both determine what the "real" E.164 numbers are that they need to = sign/verify, then the actual user string in the URI doesn't matter. >>>>>>=20 >>>>>> At first I thought that idea was crazy - that it would be too = hard to get systems along the path to be able to figure out a canonical = E.164 automatically from random user strings they get in To/=46rom URIs. = But then I realized that actually it's not hard at all, and that in = fact it's done all the time. It may require more-than-trivial = configuration, but ultimately every carrier has to actually do that type = of determination for every call that leaves/enters their domain. Well = ok, they only have to do it for international calls, but the point is a = lot of them do this type of thing already. And it's done by a lot of = systems. Even SBCs do it, using number translations or manipulation = rules or whatever. >>>>>>=20 >>>>>> So if we accept the fact that the signing and verifying domains = can and will do a canonicalization step, I'd argue part of that step is = deciding whether a received To/=46rom URI is actually an E.164 vs. an = email-style name. It would be based on the rules of the domain, and = parameters like 'user=3Dphone' can be ignored if the domain ignores it = for routing and display purposes anyway. >>>>>=20 >>>>> So as long as the part about "rules of the domain" really applies, = and it isn't done if the rules of the domain aren't known, then I'm ok. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>>=20 >>>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>>>=20 >>>>>>> OK. In a Request-URI (I was thinking more of it in a =46rom = given the context) with a + sign upfront, the entities I'm familiar with = would route it based on the TN and without it, some may even also do the = same. One may argue that those entities are not meant to support = anything else than TN-based sessions anyway. >>>>>>>=20 >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the = basics?) >>>>>>>=20 >>>>>>> It's not clear to me how any downstream entity is supposed to = route a call like that. If they follow RFCs, then they would route it = to example.com. >>>>>>> If in fact they route it based on the +CC-YYYY e.164, then it's = in scope as a TN based delegation cert. >>>>>>>=20 >>>>>>> Brian >>>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>>>=20 >>>>>>>> OK, good, thanks. And finally what if user=3DTN? = (sip:+CC-YYYYY@example.com) Does this fall into your "based on = delegation of the number" category or on the "domain entry in the DNS" = one? >>>>>>>>=20 >>>>>>>> I guess you're going to tell me that it's a "domain based = identity" where the user just happens to be digits :) >>>>>>>>=20 >>>>>>>> I'm not arguing one way or another and have some sympathy with = Paul's observation below; but I also realize as others did that we see = loads of them in real life (always treated as phone numbers I mean). My = guess is that in a stir environment two sip URIs sharing the same = canonical form as I believe those two do (with and without user=3Dphone), = could be treated as the same by the (called) endpoint though. >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>>> To: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs = and other middle boxes? >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [snip] >>>>>>>>=20 >>>>>>>>> I only bring this up because we may need to consider the = implications of >>>>>>>>> one or the other. IMO sip:+19785551212@example.com is a = private uri >>>>>>>>> belonging to example.com. It may be intended by example.com to = represent >>>>>>>>> a phone number, but I don't think anyone without special = knowledge of >>>>>>>>> example.com's policies can trust that assumption. Certainly = example.com >>>>>>>>> is free to use such a URI even if it has no rights to that = phone number. >>>>>>>>=20 >>>>>>>> [snip] >>>>>>>>=20 >>>>>>>> Philippe Fouquart >>>>>>>> Orange Labs Networks >>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>>>=20 >>>>>>>> "domain based identities" =3D identities of the form = sip:user@example.com. >>>>>>>> It DOES NOT include TN@example.com;user=3Dphone >>>>>>>>=20 >>>>>>>> Brian >>>>>>>> On Jun 19, 2013, at 12:12 PM, = wrote: >>>>>>>>=20 >>>>>>>>> This looks good to me, thanks for summing this up. For the = record, I share the observations/reservations that have already been = made on point 5 for the out-of-band mechanism and the practicalities of = a gradual deployment. >>>>>>>>>=20 >>>>>>>>> The other thing that slightly puzzles me (and that I don't = quite see in other comments) is the statement about "identities that are = domain based" ("the credentials are based on the domain entry in the DNS = "). Given that the proposed charter doesn't talk about what is meant to = be in scope in terms of URI format and what isn't, maybe this exercise = will be necessary at some point to move forward (or if this = ""domain-based identity" is meant to clarify this, my apologies, I don't = quite get it.) >>>>>>>>>=20 >>>>>>>>> This assumes that for a signed and 'uncorrupted' = sip:+CC-XXXXXX@domain.com;user=3Dphone to be validated by the endpoint, = the host part must remain untouched end-to-end since, if I read the = above correctly, the credentials for +CC-XXXXXX will have to be found = under domain.com (and I don't mean this literally in the DNS). Is this = correct? (incidentally to me this clearly restricts the use case to = calling party numbers, your point 2., since for called parties as others = have pointed out, in some networks, the host part is generally for good = or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>>>=20 >>>>>>>>> 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 Rosen, Brian >>>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>>> To: stir@ietf.org >>>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>>>=20 >>>>>>>>> A lot of our discussion is focussed on where certs are found. = I want to make sure that we agree on the basics, because where certs are = found is pretty far down the list of things to agree on. >>>>>>>>>=20 >>>>>>>>> So, do we agree: >>>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and = swatting >>>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY = of the SOURCE of the call, because we believe that spoofing identity or = non providing identity is the way the bad calls are being placed. >>>>>>>>> 3. The METHOD we're going to use is to pick some data from the = call and sign or encrypt it in a way that a downstream entity can verify = that the information is valid >>>>>>>>> 4. The CREDENTIALS we're going to use, for identities that are = telephone numbers, is based on delegation of the number, rooted in the = national numbering authority. For identities that are domain based, the = credentials are based on the domain entry in the DNS. >>>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that = has the originating device or service provider signing information and = carries the signature in the signaling. The other is some out of band = mechanism that involves some new database or service that gets written = by the originating device or service provider and checked by some = downstream entity. The latter mechanism is needed to allow the identity = to be assured even if the information or signature from the in band = mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> That doesn't say things like where the certs are or what is = signed, or what the out of band mechanism does. >>>>>>>>>=20 >>>>>>>>> So, I ask, do you agree with that? >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>> _______________________________________________ >>>>>>>>> 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, >>>>>>>>> France Telecom - 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, France Telecom - Orange is not = liable for messages that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>>>=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, >>>>>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=20 >>>>>>>=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, >>>>>>> France Telecom - 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, France Telecom - Orange is not liable = for messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=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 >>>>>=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 >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Fri Jun 21 11:52: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 CE2A021F998A for ; Fri, 21 Jun 2013 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 cIslCetA+uRw for ; Fri, 21 Jun 2013 11:52:16 -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 B224221F9811 for ; Fri, 21 Jun 2013 11:52:15 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id qypd1l0010Fqzac566s7CK; Fri, 21 Jun 2013 18:52:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id r6s61l00S3ZTu2S3U6s6TP; Fri, 21 Jun 2013 18:52:07 +0000 Message-ID: <51C4A0D6.1000903@alum.mit.edu> Date: Fri, 21 Jun 2013 14:52:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Wendt, Chris" References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> In-Reply-To: <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.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=1371840727; bh=oWBiyIjRxMO6t33qSef5ZDzX35mAo7Oof92SjOjSwVM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WXzNzZwFB0N3SfmeUuDaxR1cPf0FKyQV05XfRFqJMwOMdoARrDA7I29GIxwLdgUFg M2EUXLQcWCOn9eDRdhpm/67toe2IEnYtUzXQ1/Tzoa6h4ksrydij7w23Bh15hmV54T ObASUXb1fOlws9Gu3cXfcSNNQfCJzt76vbqK1PvtWmcuO9QzNjWi0Bpaiptjal1bYj sAYCKC+EHqOs1mLomFEEHcg0YJYQuinkUcfxKKArEj7DwSu/RLomQXNePwd+pg/x5f KCxWp6fD0Fv/53DZWBqy/r97InGnre7f6A6u+GjGdrGrjm37X9hn13SWnaJtVQ48Ru OoOFEif2+Ovyw== Cc: "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 18:52:21 -0000 On 6/20/13 1:58 PM, Wendt, Chris wrote: > No, sorry, actually the complete opposite. Depricate the use of tel uri. only use SIP URI. (you quoted me wrong, didn't say get rid of, I said get away from) Let me get this straight: You want to deprecate TEL? And you want to not use (deprecate) user=phone? And I suppose that also means you don't want to deprecate user=dialstring? So I guess you just want to reserve all user parts that are all numeric to mean "some sort of phone number or dial string thing whose syntax is vaguely defined"??? Would you allow the use of the telephone-subscriber syntax from the tel URI (with "+", separators, paramters, etc.), or do you want to deprecate that too? In that hypothetical world, is there any significance to the domain name in the URI? Are you in any way obligated to honor it when routing? If we were to do these things, then URIs for telephone numbers would be entirely context sensitive. I could never tell by examination how to process one. Thanks, Paul > -Chris > > On Jun 20, 2013, at 1:49 PM, Brian Rosen wrote: > >> Not sure what you mean by "get rid of user=phone". A sip URI with user=phone is supposed to be directly convertible into a tel uri. Are you arguing we should use tel uris as the only way to carry a telephone number based address? Note that we're discussing using a canonical e.164 as the entity we're using for the identity, so how it's encoded in the SIP message won't matter in this work. >> >> Maybe you don't get what we mean by "canonical e.164". Some examples: >> From: sip:202-555-1212@example.com;user=phone Canonical e.164=+12025551212 >> From tel:+12025551212 Canonical e.164=+12025551212 >> From: sip:12025551212@example.com (routed as a TN) Canonical e.164=+12025551212 >> From: sip:912025551212@example.com (in a PBX) Canonical e.164=+12025551212 >> From: tel:8005551212 Canonical e.164=+18005551212 >> >> By extracting the canonical e.164, we get a string that we can do a signature over that doesn't depend on that exact contents of From getting all the way through the network unchanged. For example, the call could have a From in the first example rewritten to the second example by a downstream proxy, and when it gets to the endpoint, the canonical e.164 will be the same, and therefore the signature can be verified. >> >> Brian >> >> On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: >> >>> I personally would like to get away from user=phone, but as long as there is a authoritative domain for both TN and user based routing, I'm ok. >>> >>> -Chris >>> >>> On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >>> >>>> I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity. If you route it as a user@domain address, then use a domain based identity. Both ends will use the same assumptions or the call won't get to the intended destination. >>>> >>>> Brian >>>> >>>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: >>>> >>>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>>> >>>>>> I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. >>>>> >>>>> I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call. >>>>> >>>>> But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this: >>>>> - if you route the call to the PSTN, but foo.example.com doesn't have a >>>>> connection to receive from the PSTN, its a problem. >>>>> - if the official mapping of the phone number part takes it to some >>>>> other domain than foo.example.com, that's a problem. >>>>> - if you route it to the PSTN, and it does make it back to >>>>> foo.example.com, then it may have lost important properties, >>>>> like video. >>>>> - it may be that the user part only coincidentally is made up of >>>>> digits that you happen to think look like a phone number. >>>>> >>>>> If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable. >>>>> >>>>>> At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. >>>>>> >>>>>> The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. >>>>>> >>>>>> At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. >>>>>> >>>>>> So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. >>>>> >>>>> So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>>> >>>>>>> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >>>>>>> >>>>>>> Philippe Fouquart >>>>>>> Orange Labs Networks >>>>>>> +33 (0) 1 45 29 58 13 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>>>>> >>>>>>> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >>>>>>> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >>>>>>> >>>>>>> Brian >>>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>>> >>>>>>>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>>>>>>> >>>>>>>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>>>>>>> >>>>>>>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>>> To: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>>>>>> >>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>>> I only bring this up because we may need to consider the implications of >>>>>>>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>>>>>>> belonging to example.com. It may be intended by example.com to represent >>>>>>>>> a phone number, but I don't think anyone without special knowledge of >>>>>>>>> example.com's policies can trust that assumption. Certainly example.com >>>>>>>>> is free to use such a URI even if it has no rights to that phone number. >>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> Philippe Fouquart >>>>>>>> Orange Labs Networks >>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>>> >>>>>>>> "domain based identities" = identities of the form sip:user@example.com. >>>>>>>> It DOES NOT include TN@example.com;user=phone >>>>>>>> >>>>>>>> Brian >>>>>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>>>>> >>>>>>>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>>>>>>> >>>>>>>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>>>>>>> >>>>>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>>> >>>>>>>>> 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 Rosen, Brian >>>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>>> To: stir@ietf.org >>>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>>> >>>>>>>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>>>>>>> >>>>>>>>> So, do we agree: >>>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>>>>>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>>>>>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>>> >>>>>>>>> >>>>>>>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>>>>>>> >>>>>>>>> So, I ask, do you agree with that? >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> _______________________________________________ >>>>>>>>> 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, >>>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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, >>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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, >>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 pkyzivat@alum.mit.edu Fri Jun 21 11: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 B69A021F9F1B for ; Fri, 21 Jun 2013 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 mbPwB96SGin0 for ; Fri, 21 Jun 2013 11:55:16 -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 B3D4A21F9CF2 for ; Fri, 21 Jun 2013 11:55:15 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id qzgX1l0031uE5Es556vBfS; Fri, 21 Jun 2013 18:55:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id r6vB1l00n3ZTu2S3c6vBxW; Fri, 21 Jun 2013 18:55:11 +0000 Message-ID: <51C4A18F.5040001@alum.mit.edu> Date: Fri, 21 Jun 2013 14:55:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371840911; bh=UpUSHzL3W/8yxWjGQOPTdlTP0QzR1UG5eY96Ulm7A3I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=etMhJGdVXxztT9McVKnylR37Fgb/fL+7zn/P8WZwoMecPliSbPgVZZsERUGOk8ZGt c1f6NkjB9eeKHhp0rTE3yiauCWFeYXIA2regQEvSvv0RWDKvu9mqXOZEB9WOS9+RsV tdqvD8ixZSeXlB2o9w5xb7PL9icZu0xoUz2ftwdUgmjk1fHfGpBYiDms1UqQqeinIc SWjeeu9L11ZNe2QFlyr7SCr9qvSYBGgDjhcfPo0fce1V1XLY6N266dNgaOat9ZOcRX Z5k6xr4hm1hj4270Xpj2+nphcEI4dxWk+8nqGXstckueF0xA/6sAVOkzXWkCNf+zdq av9WXYJnb6XpQ== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 18:55:20 -0000 +1 On 6/21/13 6:04 AM, philippe.fouquart@orange.com wrote: > I guess we're saying the same thing. Maybe you're more liberal than I am and I'd have no problem with that :) > > I do understand that if originating party/signer and terminating party/verifier both agree on a common implicit "context" for the digit string ("the user part I'll be sending is a number, no need for a user=phone or a '+', and I'll provide only the E.164 NDC-SN not the CC because my server can't do it and you can figure out it comes from country CC because I'll send it on trunk Y..."). I agree you don't need any particular syntactical elements to flag that it's a phone number and determine its canonical form and I know we sometimes have to do it for operational reasons. > > I would argue, however, that outside a limited remit (eg in-net or national calls, technical limitations of your vis-à-vis...), such practice doesn't scale well if the syntax you use is all over the place. It will generally become an O&M nightmare if you have as many agreements of that sort as you have interconnect bilaterals and that's why we try and stick to the identity formats defined in national or international SIP "profiles". 3966 might not be perfect in some respects but I think the principle of providing a canonical form whenever applicable or a context otherwise is well-grounded. It sometimes require very little effort for the originating party to provide a 'reasonably-canonical' form for what it sends and a lot more effort for the terminating party to manage a plethora of syntax variations and double-guess what the other guy meant (especially if you have three or four other guys in between...). > > Note, I'm not saying the solution that this group may come up with should preclude such practice (in as much as it could... indeed...) and as a matter of fact, I would hate this since as [you and] I said, it's not an uncommon operational practice. I'm just saying it's not something that should be recommended or at any rate that I would recommend as "proper engineering practice" (:-J) bearing in mind that there can be exceptions and we have to deal with those formats anyway. > > For the record, my phone may indeed display '330145295813' if "STIR treats it as an email-style name" but would definitely *reject* it "as an E.164" because it knows 0 is only the E.164 trunk prefix in the French dialing plan :) (don't hate me for this, it was hard to resist) > > 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 Hadriel Kaplan > Sent: Thursday, June 20, 2013 6:41 PM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. > > At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. > > The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. > > At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. > > So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. > > -hadriel > > > On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: > >> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >> >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >> >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, June 20, 2013 3:52 PM >> To: FOUQUART Philippe OLNC/OLN >> Cc: stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >> >> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >> >> Brian >> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >> >>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>> >>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>> >>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>> >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, June 10, 2013 10:49 PM >>>> To: stir@ietf.org >>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>> >>> >>> [snip] >>> >>>> I only bring this up because we may need to consider the implications of >>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>> belonging to example.com. It may be intended by example.com to represent >>>> a phone number, but I don't think anyone without special knowledge of >>>> example.com's policies can trust that assumption. Certainly example.com >>>> is free to use such a URI even if it has no rights to that phone number. >>> >>> [snip] >>> >>> Philippe Fouquart >>> Orange Labs Networks >>> +33 (0) 1 45 29 58 13 >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Wednesday, June 19, 2013 7:24 PM >>> To: FOUQUART Philippe OLNC/OLN >>> Cc: stir@ietf.org >>> Subject: Re: [stir] Do we agree on the basics? >>> >>> "domain based identities" = identities of the form sip:user@example.com. >>> It DOES NOT include TN@example.com;user=phone >>> >>> Brian >>> On Jun 19, 2013, at 12:12 PM, wrote: >>> >>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>> >>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>> >>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>> >>>> 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 Rosen, Brian >>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>> To: stir@ietf.org >>>> Subject: [stir] Do we agree on the basics? >>>> >>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>> >>>> So, do we agree: >>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>> 6. The credentials (4) are the same in both mechanisms (5) >>>> >>>> >>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>> >>>> So, I ask, do you agree with that? >>>> >>>> Brian >>>> _______________________________________________ >>>> 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, >>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> 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, >>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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, >> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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, > France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From pkyzivat@alum.mit.edu Fri Jun 21 11:59: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 B411C21E8135 for ; Fri, 21 Jun 2013 11:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=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 AXQCkZn0HtIZ for ; Fri, 21 Jun 2013 11:59:34 -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 0A7E021E8125 for ; Fri, 21 Jun 2013 11:59:33 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id r4LW1l0070bG4ec5B6zZ2Z; Fri, 21 Jun 2013 18:59:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id r6zZ1l0073ZTu2S3P6zZ4W; Fri, 21 Jun 2013 18:59:33 +0000 Message-ID: <51C4A293.8030102@alum.mit.edu> Date: Fri, 21 Jun 2013 14:59:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Rosen References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <51C49A86.7070106@alum.mit.edu> <97455285-D366-415A-8A29-4DC6760505CD@brianrosen.net> In-Reply-To: <97455285-D366-415A-8A29-4DC6760505CD@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371841173; bh=0hbqQxoT3IsMfEP8DJ7AVNoJfNC9H4Qr7IvvH5485nI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G+5ZdbpaZOU8rK9Ultl73FZe3CN638JB/NNGSHM0c/XpA/AEpMrG0K74PtEjeH4jg lZUqcjYdqO4+TfeUyr9uYsPWSe5570FjzPjq0tVQ3yQJlq5Wa56weNS5Yk7fdK6J79 ERS2VHfgtbHEPjDKJwWjVYJturxnwXf45nGNgu7LIUFT9XUhvP8O6AB6v9UOql5J1A PJwqN6p5Bex+ro71htbLKckQpkzeHeQP+qnXAav0BPowny8YBEwOittpM/3yPtDgQV cZl5Sl+Kci4O4vNX+wO+LOLavfSuSkJ8waZdWyQSA6DRamRouhkq1c3X0JpjnPqzCe GFn/FgtvEEI0A== Cc: stir@ietf.org, Chris Wendt Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 18:59:38 -0000 On 6/21/13 2:50 PM, Brian Rosen wrote: > Yeah, I stretched, sorry. > > I think the bottom line hasn't changed. The originator can determine what the telephone number of the termination is. It can take whatever URI is provided, and turn it into an e.164. Right now, I think we can ignore calls within a domain where there may not be an e.164 (such as within a PBX without DIDs for each extension). I think the issue is the one Philippe raised: if we don't impose *some* constraints on how numbers are represented, then the two ends may not do the canonicalization in a consistent way. Thanks, Paul > Brian > > On Jun 21, 2013, at 2:25 PM, Paul Kyzivat wrote: > >> On 6/20/13 1:49 PM, Brian Rosen wrote: >>> Not sure what you mean by "get rid of user=phone". A sip URI with user=phone is supposed to be directly convertible into a tel uri. >> >> By my reading of 3261, you are stretching the definition of user=phone. 3261 says: >> >> The set of valid telephone-subscriber strings is a subset of >> valid user strings. The user URI parameter exists to >> distinguish telephone numbers from user names that happen to >> look like telephone numbers. If the user string contains a >> telephone number formatted as a telephone-subscriber, the user >> parameter value "phone" SHOULD be present. Even without this >> parameter, recipients of SIP and SIPS URIs MAY interpret the >> pre-@ part as a telephone number if local restrictions on the >> name space for user name allow it. >> >> The above is unfortunately limited in many respects: >> >> - it *doesn't* say "if the user string is *not* formatted as a >> telephone-subscriber then the user parameter value "phone" MUST NOT >> be present." But even so, I read between the lines and conclude that >> this is intended. So IMO >> is a non-conforming usage. >> >> - it most definitely doesn't say "if user=phone is present you may >> ignore the domain when routing the request." If a sip URI with >> user=phone were converted to a tel: uri then that would result >> in ignoring the domain when routing. >> >> - I find the last sentence significant, because it talks about local >> restrictions on the namespace. Local to whom? IMO the only thing >> that makes sense is "if restrictions by the domain on the namespace >> for user name allow it." And that means you can't infer this >> unless you are *aware* of the namespace policies for the domain. >> >> Thanks, >> Paul >> >>> Are you arguing we should use tel uris as the only way to carry a telephone number based address? Note that we're discussing using a canonical e.164 as the entity we're using for the identity, so how it's encoded in the SIP message won't matter in this work. >>> >>> Maybe you don't get what we mean by "canonical e.164". Some examples: >>> From: sip:202-555-1212@example.com;user=phone Canonical e.164=+12025551212 >>> From tel:+12025551212 Canonical e.164=+12025551212 >>> From: sip:12025551212@example.com (routed as a TN) Canonical e.164=+12025551212 >>> From: sip:912025551212@example.com (in a PBX) Canonical e.164=+12025551212 >>> From: tel:8005551212 Canonical e.164=+18005551212 >>> >>> By extracting the canonical e.164, we get a string that we can do a signature over that doesn't depend on that exact contents of From getting all the way through the network unchanged. For example, the call could have a From in the first example rewritten to the second example by a downstream proxy, and when it gets to the endpoint, the canonical e.164 will be the same, and therefore the signature can be verified. >>> >>> Brian >>> >>> On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: >>> >>>> I personally would like to get away from user=phone, but as long as there is a authoritative domain for both TN and user based routing, I'm ok. >>>> >>>> -Chris >>>> >>>> On Jun 20, 2013, at 1:17 PM, Brian Rosen wrote: >>>> >>>>> I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity. If you route it as a user@domain address, then use a domain based identity. Both ends will use the same assumptions or the call won't get to the intended destination. >>>>> >>>>> Brian >>>>> >>>>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat wrote: >>>>> >>>>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>>>> >>>>>>> I don't think it matters at all whether there's a 'user=phone' param or not. Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire. Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone. It's been that way for many years in SIP. >>>>>> >>>>>> I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call. >>>>>> >>>>>> But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this: >>>>>> - if you route the call to the PSTN, but foo.example.com doesn't have a >>>>>> connection to receive from the PSTN, its a problem. >>>>>> - if the official mapping of the phone number part takes it to some >>>>>> other domain than foo.example.com, that's a problem. >>>>>> - if you route it to the PSTN, and it does make it back to >>>>>> foo.example.com, then it may have lost important properties, >>>>>> like video. >>>>>> - it may be that the user part only coincidentally is made up of >>>>>> digits that you happen to think look like a phone number. >>>>>> >>>>>> If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable. >>>>>> >>>>>>> At a high level, it doesn't matter how something appears on-the-wire. If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number. Otherwise, if foo.com sends a From URI of 'sip:330145295813@foo.com', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number. >>>>>>> >>>>>>> The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs. One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever. But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter. >>>>>>> >>>>>>> At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs. But then I realized that actually it's not hard at all, and that in fact it's done all the time. It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain. Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already. And it's done by a lot of systems. Even SBCs do it, using number translations or manipulation rules or whatever. >>>>>>> >>>>>>> So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name. It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway. >>>>>> >>>>>> So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> >>>>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com wrote: >>>>>>> >>>>>>>> OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. >>>>>>>> >>>>>>>> Philippe Fouquart >>>>>>>> Orange Labs Networks >>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>>>>>> >>>>>>>> It's not clear to me how any downstream entity is supposed to route a call like that. If they follow RFCs, then they would route it to example.com. >>>>>>>> If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert. >>>>>>>> >>>>>>>> Brian >>>>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com wrote: >>>>>>>> >>>>>>>>> OK, good, thanks. And finally what if user=TN? (sip:+CC-YYYYY@example.com) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one? >>>>>>>>> >>>>>>>>> I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :) >>>>>>>>> >>>>>>>>> I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>>>> To: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes? >>>>>>>>>> >>>>>>>>> >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>>> I only bring this up because we may need to consider the implications of >>>>>>>>>> one or the other. IMO sip:+19785551212@example.com is a private uri >>>>>>>>>> belonging to example.com. It may be intended by example.com to represent >>>>>>>>>> a phone number, but I don't think anyone without special knowledge of >>>>>>>>>> example.com's policies can trust that assumption. Certainly example.com >>>>>>>>>> is free to use such a URI even if it has no rights to that phone number. >>>>>>>>> >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>> Philippe Fouquart >>>>>>>>> Orange Labs Networks >>>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>>>> >>>>>>>>> "domain based identities" = identities of the form sip:user@example.com. >>>>>>>>> It DOES NOT include TN@example.com;user=phone >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> On Jun 19, 2013, at 12:12 PM, wrote: >>>>>>>>> >>>>>>>>>> This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment. >>>>>>>>>> >>>>>>>>>> The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) >>>>>>>>>> >>>>>>>>>> This assumes that for a signed and 'uncorrupted' sip:+CC-XXXXXX@domain.com;user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>>>> >>>>>>>>>> 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 Rosen, Brian >>>>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>>>> To: stir@ietf.org >>>>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>>>> >>>>>>>>>> A lot of our discussion is focussed on where certs are found. I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on. >>>>>>>>>> >>>>>>>>>> So, do we agree: >>>>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and swatting >>>>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed. >>>>>>>>>> 3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid >>>>>>>>>> 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority. For identities that are domain based, the credentials are based on the domain entry in the DNS. >>>>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling. The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity. The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does. >>>>>>>>>> >>>>>>>>>> So, I ask, do you agree with that? >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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, >>>>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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, >>>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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, >>>>>>>> France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 br@brianrosen.net Fri Jun 21 12:13: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 D9EB921F9F90 for ; Fri, 21 Jun 2013 12:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.678 X-Spam-Level: X-Spam-Status: No, score=-99.678 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.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 hDBImdBpnQRX for ; Fri, 21 Jun 2013 12:13:06 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0313221F9F8D for ; Fri, 21 Jun 2013 12:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=+NispW0kjW9Z4Co9nRjUqy30J97GQZXbsSYwVPQtFZc=; b=XACOvZ4RhqqHWUuFroI4OxjaAaKSwclNbNh6y3Y79HVgtkmLII9CYfqXwMXesPT8d7/c96O4oPAt6ppkjG/jZgqFUnfysqfgHi+cQ22PkZWZ7jtY5OKSd1zkPTt50c5QyghqrxwxX6UGXhfD/HIOKBr8oOHfHnOQfKahgRc1O8c=; Received: from neustargw.va.neustar.com ([209.173.53.233]:38104 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uq6lb-0006PE-GF; Fri, 21 Jun 2013 15:13:03 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51C4A293.8030102@alum.mit.edu> Date: Fri, 21 Jun 2013 15:13:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11693079-4BCD-4C92-8033-02C4813A70ED@brianrosen.net> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <51C49A86.7070106@alum.mit.edu> <97455285-D366-415A-8A29-4DC6760505CD@brianrosen.net> <51C4A293.8030102@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Chris Wendt Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 19:13:11 -0000 I think that the To part is pretty easy or the call wouldn't route. The = =46rom may have some issues. Specifically, you sometimes see local = numbers and an international call couldn't easily determine the = canonical e.164 from that at the termination. We may have to do = something there. Brian On Jun 21, 2013, at 2:59 PM, Paul Kyzivat wrote: > On 6/21/13 2:50 PM, Brian Rosen wrote: >> Yeah, I stretched, sorry. >>=20 >> I think the bottom line hasn't changed. The originator can determine = what the telephone number of the termination is. It can take whatever = URI is provided, and turn it into an e.164. Right now, I think we can = ignore calls within a domain where there may not be an e.164 (such as = within a PBX without DIDs for each extension). >=20 > I think the issue is the one Philippe raised: if we don't impose = *some* constraints on how numbers are represented, then the two ends may = not do the canonicalization in a consistent way. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Jun 21, 2013, at 2:25 PM, Paul Kyzivat = wrote: >>=20 >>> On 6/20/13 1:49 PM, Brian Rosen wrote: >>>> Not sure what you mean by "get rid of user=3Dphone". A sip URI = with user=3Dphone is supposed to be directly convertible into a tel uri. >>>=20 >>> By my reading of 3261, you are stretching the definition of = user=3Dphone. 3261 says: >>>=20 >>> The set of valid telephone-subscriber strings is a subset of >>> valid user strings. The user URI parameter exists to >>> distinguish telephone numbers from user names that happen to >>> look like telephone numbers. If the user string contains a >>> telephone number formatted as a telephone-subscriber, the = user >>> parameter value "phone" SHOULD be present. Even without = this >>> parameter, recipients of SIP and SIPS URIs MAY interpret the >>> pre-@ part as a telephone number if local restrictions on = the >>> name space for user name allow it. >>>=20 >>> The above is unfortunately limited in many respects: >>>=20 >>> - it *doesn't* say "if the user string is *not* formatted as a >>> telephone-subscriber then the user parameter value "phone" MUST NOT >>> be present." But even so, I read between the lines and conclude = that >>> this is intended. So IMO >>> is a non-conforming usage. >>>=20 >>> - it most definitely doesn't say "if user=3Dphone is present you may >>> ignore the domain when routing the request." If a sip URI with >>> user=3Dphone were converted to a tel: uri then that would result >>> in ignoring the domain when routing. >>>=20 >>> - I find the last sentence significant, because it talks about local >>> restrictions on the namespace. Local to whom? IMO the only thing >>> that makes sense is "if restrictions by the domain on the namespace >>> for user name allow it." And that means you can't infer this >>> unless you are *aware* of the namespace policies for the domain. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Are you arguing we should use tel uris as the only way to carry a = telephone number based address? Note that we're discussing using a = canonical e.164 as the entity we're using for the identity, so how it's = encoded in the SIP message won't matter in this work. >>>>=20 >>>> Maybe you don't get what we mean by "canonical e.164". Some = examples: >>>> From: sip:202-555-1212@example.com;user=3Dphone Canonical = e.164=3D+12025551212 >>>> =46rom tel:+12025551212 Canonical e.164=3D+12025551212 >>>> From: sip:12025551212@example.com (routed as a TN) Canonical = e.164=3D+12025551212 >>>> From: sip:912025551212@example.com (in a PBX) Canonical = e.164=3D+12025551212 >>>> From: tel:8005551212 Canonical e.164=3D+18005551212 >>>>=20 >>>> By extracting the canonical e.164, we get a string that we can do a = signature over that doesn't depend on that exact contents of =46rom = getting all the way through the network unchanged. For example, the = call could have a =46rom in the first example rewritten to the second = example by a downstream proxy, and when it gets to the endpoint, the = canonical e.164 will be the same, and therefore the signature can be = verified. >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 20, 2013, at 1:28 PM, Chris Wendt wrote: >>>>=20 >>>>> I personally would like to get away from user=3Dphone, but as long = as there is a authoritative domain for both TN and user based routing, = I'm ok. >>>>>=20 >>>>> -Chris >>>>>=20 >>>>> On Jun 20, 2013, at 1:17 PM, Brian Rosen = wrote: >>>>>=20 >>>>>> I think Hadriel got it right - if you will route it based on the = phone number, then use a phone number based identity. If you route it = as a user@domain address, then use a domain based identity. Both ends = will use the same assumptions or the call won't get to the intended = destination. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Jun 20, 2013, at 1:06 PM, Paul Kyzivat = wrote: >>>>>>=20 >>>>>>> On 6/20/13 12:41 PM, Hadriel Kaplan wrote: >>>>>>>>=20 >>>>>>>> I don't think it matters at all whether there's a 'user=3Dphone' = param or not. Brian's right that that's what *should* be in the URI, = but we all know that isn't what happens on-the-wire. Whether there's a = 'user=3Dphone' or not, or even a leading '+' or not, if the user portion = of the URI looks like a phone number and smells like a phone number, its = treated as a phone number by virtually everyone. It's been that way for = many years in SIP. >>>>>>>=20 >>>>>>> I have no problem with somebody using specific knowledge of how = domain foo.example.com manages user parts to decide that the sip URI = with that domain is a phone number, and then use the phone number to = route the call. >>>>>>>=20 >>>>>>> But it is a serious problem if that is done *without* any = knowledge of the target domain. Some issues with this: >>>>>>> - if you route the call to the PSTN, but foo.example.com doesn't = have a >>>>>>> connection to receive from the PSTN, its a problem. >>>>>>> - if the official mapping of the phone number part takes it to = some >>>>>>> other domain than foo.example.com, that's a problem. >>>>>>> - if you route it to the PSTN, and it does make it back to >>>>>>> foo.example.com, then it may have lost important properties, >>>>>>> like video. >>>>>>> - it may be that the user part only coincidentally is made up of >>>>>>> digits that you happen to think look like a phone number. >>>>>>>=20 >>>>>>> If this is considered acceptable behavior, then we have = effectively declared that all user parts that even remotely resemble a = phone number are reserved, and can only be used in cases where = gatewaying to PSTN is acceptable. >>>>>>>=20 >>>>>>>> At a high level, it doesn't matter how something appears = on-the-wire. If the terminating domain *treats* it as a phone number, = and displays to the user only a phone number caller-id, then we need to = validate it as a phone number. Otherwise, if foo.com sends a =46rom URI = of 'sip:330145295813@foo.com', and STIR treats it as an email-style name = instead of E.164, but your phone displays '330145295813', then foo.com = will have successfully spoofed your number. >>>>>>>>=20 >>>>>>>> The really important point/concept Brian made in another email = thread earlier, I think, was the idea of determining a canonical E.164 = number from the To/=46rom URIs. One of his points there was that sure = the encoded number in the URI may have a prefix of digits, or is missing = the country-code because it's in national form, or it has visual = separators in it, or whatever. But as long as the signer and verifier = can both determine what the "real" E.164 numbers are that they need to = sign/verify, then the actual user string in the URI doesn't matter. >>>>>>>>=20 >>>>>>>> At first I thought that idea was crazy - that it would be too = hard to get systems along the path to be able to figure out a canonical = E.164 automatically from random user strings they get in To/=46rom URIs. = But then I realized that actually it's not hard at all, and that in = fact it's done all the time. It may require more-than-trivial = configuration, but ultimately every carrier has to actually do that type = of determination for every call that leaves/enters their domain. Well = ok, they only have to do it for international calls, but the point is a = lot of them do this type of thing already. And it's done by a lot of = systems. Even SBCs do it, using number translations or manipulation = rules or whatever. >>>>>>>>=20 >>>>>>>> So if we accept the fact that the signing and verifying domains = can and will do a canonicalization step, I'd argue part of that step is = deciding whether a received To/=46rom URI is actually an E.164 vs. an = email-style name. It would be based on the rules of the domain, and = parameters like 'user=3Dphone' can be ignored if the domain ignores it = for routing and display purposes anyway. >>>>>>>=20 >>>>>>> So as long as the part about "rules of the domain" really = applies, and it isn't done if the rules of the domain aren't known, then = I'm ok. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 20, 2013, at 10:17 AM, philippe.fouquart@orange.com = wrote: >>>>>>>>=20 >>>>>>>>> OK. In a Request-URI (I was thinking more of it in a =46rom = given the context) with a + sign upfront, the entities I'm familiar with = would route it based on the TN and without it, some may even also do the = same. One may argue that those entities are not meant to support = anything else than TN-based sessions anyway. >>>>>>>>>=20 >>>>>>>>> Philippe Fouquart >>>>>>>>> Orange Labs Networks >>>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>>> Sent: Thursday, June 20, 2013 3:52 PM >>>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the = basics?) >>>>>>>>>=20 >>>>>>>>> It's not clear to me how any downstream entity is supposed to = route a call like that. If they follow RFCs, then they would route it = to example.com. >>>>>>>>> If in fact they route it based on the +CC-YYYY e.164, then = it's in scope as a TN based delegation cert. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>> On Jun 20, 2013, at 5:37 AM, philippe.fouquart@orange.com = wrote: >>>>>>>>>=20 >>>>>>>>>> OK, good, thanks. And finally what if user=3DTN? = (sip:+CC-YYYYY@example.com) Does this fall into your "based on = delegation of the number" category or on the "domain entry in the DNS" = one? >>>>>>>>>>=20 >>>>>>>>>> I guess you're going to tell me that it's a "domain based = identity" where the user just happens to be digits :) >>>>>>>>>>=20 >>>>>>>>>> I'm not arguing one way or another and have some sympathy = with Paul's observation below; but I also realize as others did that we = see loads of them in real life (always treated as phone numbers I mean). = My guess is that in a stir environment two sip URIs sharing the same = canonical form as I believe those two do (with and without user=3Dphone), = could be treated as the same by the (called) endpoint though. >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On Behalf Of Paul Kyzivat >>>>>>>>>>> Sent: Monday, June 10, 2013 10:49 PM >>>>>>>>>>> To: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Can canonical phone numbers survive SBCs = and other middle boxes? >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> [snip] >>>>>>>>>>=20 >>>>>>>>>>> I only bring this up because we may need to consider the = implications of >>>>>>>>>>> one or the other. IMO sip:+19785551212@example.com is a = private uri >>>>>>>>>>> belonging to example.com. It may be intended by example.com = to represent >>>>>>>>>>> a phone number, but I don't think anyone without special = knowledge of >>>>>>>>>>> example.com's policies can trust that assumption. Certainly = example.com >>>>>>>>>>> is free to use such a URI even if it has no rights to that = phone number. >>>>>>>>>>=20 >>>>>>>>>> [snip] >>>>>>>>>>=20 >>>>>>>>>> Philippe Fouquart >>>>>>>>>> Orange Labs Networks >>>>>>>>>> +33 (0) 1 45 29 58 13 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>>>>> Sent: Wednesday, June 19, 2013 7:24 PM >>>>>>>>>> To: FOUQUART Philippe OLNC/OLN >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Do we agree on the basics? >>>>>>>>>>=20 >>>>>>>>>> "domain based identities" =3D identities of the form = sip:user@example.com. >>>>>>>>>> It DOES NOT include TN@example.com;user=3Dphone >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>> On Jun 19, 2013, at 12:12 PM, = wrote: >>>>>>>>>>=20 >>>>>>>>>>> This looks good to me, thanks for summing this up. For the = record, I share the observations/reservations that have already been = made on point 5 for the out-of-band mechanism and the practicalities of = a gradual deployment. >>>>>>>>>>>=20 >>>>>>>>>>> The other thing that slightly puzzles me (and that I don't = quite see in other comments) is the statement about "identities that are = domain based" ("the credentials are based on the domain entry in the DNS = "). Given that the proposed charter doesn't talk about what is meant to = be in scope in terms of URI format and what isn't, maybe this exercise = will be necessary at some point to move forward (or if this = ""domain-based identity" is meant to clarify this, my apologies, I don't = quite get it.) >>>>>>>>>>>=20 >>>>>>>>>>> This assumes that for a signed and 'uncorrupted' = sip:+CC-XXXXXX@domain.com;user=3Dphone to be validated by the endpoint, = the host part must remain untouched end-to-end since, if I read the = above correctly, the credentials for +CC-XXXXXX will have to be found = under domain.com (and I don't mean this literally in the DNS). Is this = correct? (incidentally to me this clearly restricts the use case to = calling party numbers, your point 2., since for called parties as others = have pointed out, in some networks, the host part is generally for good = or bad irrelevant when the SIP URI conveys an encapsulated tel) >>>>>>>>>>>=20 >>>>>>>>>>> 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 Rosen, Brian >>>>>>>>>>> Sent: Wednesday, June 19, 2013 3:52 PM >>>>>>>>>>> To: stir@ietf.org >>>>>>>>>>> Subject: [stir] Do we agree on the basics? >>>>>>>>>>>=20 >>>>>>>>>>> A lot of our discussion is focussed on where certs are = found. I want to make sure that we agree on the basics, because where = certs are found is pretty far down the list of things to agree on. >>>>>>>>>>>=20 >>>>>>>>>>> So, do we agree: >>>>>>>>>>> 1. The PROBLEM we're solving is robocalling, vishing and = swatting >>>>>>>>>>> 2. The APPROACH we're going to use is to verify the IDENTITY = of the SOURCE of the call, because we believe that spoofing identity or = non providing identity is the way the bad calls are being placed. >>>>>>>>>>> 3. The METHOD we're going to use is to pick some data from = the call and sign or encrypt it in a way that a downstream entity can = verify that the information is valid >>>>>>>>>>> 4. The CREDENTIALS we're going to use, for identities that = are telephone numbers, is based on delegation of the number, rooted in = the national numbering authority. For identities that are domain based, = the credentials are based on the domain entry in the DNS. >>>>>>>>>>> 5. We think we need two MECHANISMS, an in-band mechanism = that has the originating device or service provider signing information = and carries the signature in the signaling. The other is some out of = band mechanism that involves some new database or service that gets = written by the originating device or service provider and checked by = some downstream entity. The latter mechanism is needed to allow the = identity to be assured even if the information or signature from the in = band mechanism is lost (such as when the call goes through an SS7 hop). >>>>>>>>>>> 6. The credentials (4) are the same in both mechanisms (5) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> That doesn't say things like where the certs are or what is = signed, or what the out of band mechanism does. >>>>>>>>>>>=20 >>>>>>>>>>> So, I ask, do you agree with that? >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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, >>>>>>>>>>> France Telecom - 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, France Telecom - Orange is not = liable for messages that have been modified, changed or falsified. >>>>>>>>>>> Thank you. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>>=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, >>>>>>>>>> France Telecom - 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, France Telecom - Orange is not = liable for messages that have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>>=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, >>>>>>>>> France Telecom - 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, France Telecom - Orange is not = liable for messages that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=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 >>>>>>>=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 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Fri Jun 21 13:47: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 49EE921F9D62 for ; Fri, 21 Jun 2013 13:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.139, 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 zXSDBR+EGYFe for ; Fri, 21 Jun 2013 13:47:18 -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 521B721F9AFF for ; Fri, 21 Jun 2013 13:47:17 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id r7e51l0041ei1Bg518nHa1; Fri, 21 Jun 2013 20:47:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id r8nH1l0093ZTu2S3k8nH3c; Fri, 21 Jun 2013 20:47:17 +0000 Message-ID: <51C4BBD4.5030208@alum.mit.edu> Date: Fri, 21 Jun 2013 16:47:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> In-Reply-To: <988AB632-7E4D-4D39-96C8-2179134F3A3D@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=1371847637; bh=RVJxmTdSyzszDTnUttZpsvur2VXmKxKYvE2aI10eDhs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=laIVFpQse7AIyY7QHZmk3CNr+6N6gZGZU/K7ON3X4b85z5epBdWF8ilxIEMtDvN40 bPxjWfYGJWCPyjIp/StlgeBkrTVYtSK1/piEoihj3k5FJzbAv5TOm/9/5IWpptV+Ro pp5zQBgAIf4l7zKddwSg24etu4Cn/JnZpSvOBXpC9/qv9VtSdwl1zAZjMuUJ+SS6F+ AlA7j+TQT4w5w3w/K/bDjW05HG3kGuThu/pUEQ8lnAVf+ueMEwZnFQsrxdJvtOSZyD wYobjV1AVHRIkSVhY6/m3vNQEBrTFtzxzjcGixEvwTdKrrECk0BxHilnCTm4yAARKe oZCF88BniVOdQ== Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 20:47:24 -0000 On 6/20/13 3:46 PM, Hadriel Kaplan wrote: > And there's no "new" money for this - this stuff doesn't create a new revenue-generating feature, nor a feature one can use for competitive advantage. This thing is just a cost sink: another red line item for opex and capex, with no black line to offset it. It's got to be as cheap as possible. And it's got to be something we think will actually *work*. We can be wrong in the end of course, but we can't believe we'll be wrong from the start! What about the $5/month fee for "block spam calls"? :-) Thanks, Paul From hadriel.kaplan@oracle.com Fri Jun 21 14:12: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 9223A21F9D8B for ; Fri, 21 Jun 2013 14:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.249 X-Spam-Level: X-Spam-Status: No, score=-7.249 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_45=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 i7NobAlB35Kb for ; Fri, 21 Jun 2013 14:12:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 144CE21F9D8A for ; Fri, 21 Jun 2013 14:11:59 -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 r5LL5coA028683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 21:05:38 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 r5LLBshm027893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 21:11:54 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LLBrDJ014950; Fri, 21 Jun 2013 21:11:53 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 14:11:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C4A0D6.1000903@alum.mit.edu> Date: Fri, 21 Jun 2013 17:11:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Wendt, Chris" , Brian Rosen , "" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 21:12:06 -0000 On Jun 21, 2013, at 2:52 PM, Paul Kyzivat wrote: > On 6/20/13 1:58 PM, Wendt, Chris wrote: >> No, sorry, actually the complete opposite. Depricate the use of tel = uri. only use SIP URI. (you quoted me wrong, didn't say get rid of, I = said get away from) >=20 > Let me get this straight: >=20 > You want to deprecate TEL? > And you want to not use (deprecate) user=3Dphone? > And I suppose that also means you don't want to deprecate = user=3Ddialstring? > So I guess you just want to reserve all user parts that are all = numeric to mean "some sort of phone number or dial string thing whose = syntax is vaguely defined"??? > Would you allow the use of the telephone-subscriber syntax from the = tel URI (with "+", separators, paramters, etc.), or do you want to = deprecate that too? I think what Chris is saying is that in the real world that's generally = the case: TEL URI is rarely seen, the existence or lack thereof for = 'user=3Dphone' is ignored, 'user=3Ddialstring' is rarely ever seen, and = all user names of digits do in fact require contextual knowledge that = does not exist in the URI. And the truth is he's right, at least in the majority sense. But I think you're also right: in the IETF we can't deprecate or ignore = them. We need to have them to make our specs self-consistent, and we = don't want to presume a specific deployment model and make different = rules for each device in it, and we want it to be possible to handle = digit-based usernames with a "do what I say not what I mean" model. = Whether they actually can be or not in the real world today doesn't = matter - they could be if everyone followed the rules in the RFCs. I'm not saying the IETF is wrong to ignore the real world - for one = thing there's probably *some* SIP domain of SIP devices somewhere that = actually follow the RFCs sufficiently to use that stuff, and for that = reason we wouldn't deprecate it; and there are certainly specific SIP = hops/devices in general where those rules do apply, and they're doing = the "right thing", and for that reason we wouldn't deprecate it as well. But for people actually using this stuff - building products, deploying = it all, managing the service - for them it's frustrating that the IETF = RFCs don't line up with the reality as shown by Wireshark. Unfortunately there is no solution for this. It's the nature of = standards organizations to keep their specs self-consistent, to not = change their view unless it can be proven that something's fundamentally = broken if their view is followed, to not even be able to change their = view unless it can be proven that absolutely no one follows it, etc. And the IETF's not alone in having that problem. The 3GPP IMS specs = have the same problem - no one actually follows all the specs = to-the-letter; not if you look at Wireshark traces. Things would break = if they tried to follow them precisely. The same with the specs that = many country-specific SDOs generate. Thank god we have Wireshark. :) -hadriel From pkyzivat@alum.mit.edu Fri Jun 21 14:31: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 B7F2821F9AF8 for ; Fri, 21 Jun 2013 14:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=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 OTySCFeb-oPh for ; Fri, 21 Jun 2013 14:31:38 -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 38F7F21F9B29 for ; Fri, 21 Jun 2013 14:31:33 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id qzzJ1l00816LCl05C9XWLx; Fri, 21 Jun 2013 21:31:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id r9XV1l0183ZTu2S3S9XVDp; Fri, 21 Jun 2013 21:31:30 +0000 Message-ID: <51C4C631.2000802@alum.mit.edu> Date: Fri, 21 Jun 2013 17:31:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@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=1371850290; bh=Fjvb0g3ADRbHJ/mJ0LZSHRDZM+GaE9/ywijtBssU9gM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S9OyHTm37buzI5lk9KjH2vvYbzUchw+MfkMwFy8a9OGoIi8FoLXzkGHeH1C2AIEa5 YA7Rd0GaQEdU5cAvTcqieHtKv+Y7T5QYCulwoLYhlsaMMhfVz/iPSRqwVS3QXX+GwQ x+mfozVsV6zljz+CSHodvTbN/0xq4FUhZrpY6kgq6o13kOFZuTO8lsW8kuqn/hTfkj I601cx4cpLbZbxUpefKFsYc1nlbjPu7XosD/xiYLxa+d1UZrrNt6qEWf9VxwnfQguw rmlVH/I3TVhM0BZ8N6nAXuvnM7gUcy+oRQGLD+f/nwPiMEHMvGu8Qvxxj+AslCXpCs ZfqTj6cB4VtTg== Cc: "Wendt, Chris" , Brian Rosen , "" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 21:31:43 -0000 On 6/21/13 5:11 PM, Hadriel Kaplan wrote: > > On Jun 21, 2013, at 2:52 PM, Paul Kyzivat wrote: > >> On 6/20/13 1:58 PM, Wendt, Chris wrote: >>> No, sorry, actually the complete opposite. Depricate the use of tel uri. only use SIP URI. (you quoted me wrong, didn't say get rid of, I said get away from) >> >> Let me get this straight: >> >> You want to deprecate TEL? >> And you want to not use (deprecate) user=phone? >> And I suppose that also means you don't want to deprecate user=dialstring? >> So I guess you just want to reserve all user parts that are all numeric to mean "some sort of phone number or dial string thing whose syntax is vaguely defined"??? >> Would you allow the use of the telephone-subscriber syntax from the tel URI (with "+", separators, paramters, etc.), or do you want to deprecate that too? > > I think what Chris is saying is that in the real world that's generally the case: TEL URI is rarely seen, the existence or lack thereof for 'user=phone' is ignored, 'user=dialstring' is rarely ever seen, and all user names of digits do in fact require contextual knowledge that does not exist in the URI. > > And the truth is he's right, at least in the majority sense. > > But I think you're also right: in the IETF we can't deprecate or ignore them. We need to have them to make our specs self-consistent, and we don't want to presume a specific deployment model and make different rules for each device in it, and we want it to be possible to handle digit-based usernames with a "do what I say not what I mean" model. Whether they actually can be or not in the real world today doesn't matter - they could be if everyone followed the rules in the RFCs. > > I'm not saying the IETF is wrong to ignore the real world - for one thing there's probably *some* SIP domain of SIP devices somewhere that actually follow the RFCs sufficiently to use that stuff, and for that reason we wouldn't deprecate it; and there are certainly specific SIP hops/devices in general where those rules do apply, and they're doing the "right thing", and for that reason we wouldn't deprecate it as well. > > But for people actually using this stuff - building products, deploying it all, managing the service - for them it's frustrating that the IETF RFCs don't line up with the reality as shown by Wireshark. And this will work for them as long as they live in their sheltered garden, OR, as long as they deploy SBCs at the boundaries of their garden to preserve their naive assumptions. So its no problem for you - its just a way to preserve your business model. :-) But you are right that we (IETF) really don't need to, and probably shouldn't, worry aobut that, because that is a problem for the SBCs of the world. What we define should actually work in and E2E model with no SBCs rewriting everything along the way. And then that should actually become a usable model for what ought to flow *between* SBCs, so that its not necessary to negotiate n^2 number transformations. But I still have to ask: Why *wouldn't* those using telephone numbers *want* to use TEL URIs for From, To, and P-A-ID headers? This eliminates those domain names that have no relevance to how the URIs are used. Is it simply "we don't do it that way and see no reason to change"? Thanks, Paul > Unfortunately there is no solution for this. It's the nature of standards organizations to keep their specs self-consistent, to not change their view unless it can be proven that something's fundamentally broken if their view is followed, to not even be able to change their view unless it can be proven that absolutely no one follows it, etc. > > And the IETF's not alone in having that problem. The 3GPP IMS specs have the same problem - no one actually follows all the specs to-the-letter; not if you look at Wireshark traces. Things would break if they tried to follow them precisely. The same with the specs that many country-specific SDOs generate. > > Thank god we have Wireshark. :) > > -hadriel > > > From richard@shockey.us Fri Jun 21 14:56: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 4027821F9E60 for ; Fri, 21 Jun 2013 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=1.311, 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 A3-xoe+fesYm for ; Fri, 21 Jun 2013 14:55:50 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 762AF21F9E5C for ; Fri, 21 Jun 2013 14:55:49 -0700 (PDT) Received: (qmail 29371 invoked by uid 0); 21 Jun 2013 21:55:15 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 21 Jun 2013 21:55:15 -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=8kCWuvKIQOocw/VoihWDlLkLs/CzLBAYMwPG0f45To0=; b=K55e9OU8CL+ZVVz62eLlARqebqokCXxJo2suGEYWI2vw795F3gqNj4A88ukMtdXCnnH/51OqADApkRtHwRed5JHn4r4TxhNXSe93gCRP66xagS+pBY4bF22jA1nD0KSx; Received: from [72.66.111.124] (port=56612 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uq9IZ-0004uu-9K; Fri, 21 Jun 2013 15:55:15 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Hadriel Kaplan'" References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> In-Reply-To: <51C4C631.2000802@alum.mit.edu> Date: Fri, 21 Jun 2013 17:55:12 -0400 Message-ID: <00e001ce6eca$028b5d20$07a21760$@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: AQHAjWxiYKyeFeQ0QFi1FrZzZNPRqwLu/i1QAkpVP5kB3t7wMAGjnJZ/AX9eKEsB7glrtgJaP7MDAlqCOOMBJy/epAIeaEXNAaLT2egAtyefRAGfjA6/AQq+qrKYkzRh4A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: "'Wendt, Chris'" , stir@ietf.org, 'Brian Rosen' Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 21:56:01 -0000 > > I think what Chris is saying is that in the real world that's generally the case: TEL URI is rarely seen, the existence or lack thereof for 'user=phone' is ignored, 'user=dialstring' is rarely ever seen, and all user names of digits do in fact require contextual knowledge that does not exist in the URI. > > And the truth is he's right, at least in the majority sense. > > But I think you're also right: in the IETF we can't deprecate or ignore them. We need to have them to make our specs self-consistent, and we don't want to presume a specific deployment model and make different rules for each device in it, and we want it to be possible to handle digit-based usernames with a "do what I say not what I mean" model. Whether they actually can be or not in the real world today doesn't matter - they could be if everyone followed the rules in the RFCs. > > I'm not saying the IETF is wrong to ignore the real world - for one thing there's probably *some* SIP domain of SIP devices somewhere that actually follow the RFCs sufficiently to use that stuff, and for that reason we wouldn't deprecate it; and there are certainly specific SIP hops/devices in general where those rules do apply, and they're doing the "right thing", and for that reason we wouldn't deprecate it as well. > > But for people actually using this stuff - building products, deploying it all, managing the service - for them it's frustrating that the IETF RFCs don't line up with the reality as shown by Wireshark. And this will work for them as long as they live in their sheltered garden, [RS> ] Well the carriers are the institutions that have to support the STIR mechanism and there WILL be some serious discussion about what practically possible for deployment. Personally I believe anything that looks like HTTP is a non-starter. It will not deploy in the time frames envisioned. Not that I have a particular love for DNS. It's just I know what is actually deployed and there is a LOT of DNS for number translations out there. IN the US that means virtually all Cable, Verizon FIOS, ATT uVerse and a substantial amount of Enterprise SIP Trunking environments. Though SIP redirect for intra-carrier routing is widely deployed as well. OR, as long as they deploy SBCs at the boundaries of their garden to preserve their naive assumptions. [RS> ] Every single institution deploying SIP either at the carrier layer or enterprise is using a SBC. There is no naivety here. So its no problem for you - its just a way to preserve your business model. :-) [RS> ] Well it seems there a lot of companies looking to preserve business models around here :-) .. but that aside SBC's exist for the practical reasons Hadriel describes one AAA to be sure but normalizing the SIP headers to actually make them work is the biggest reason. CSCF and SIP proxy vendors that write weird code that it takes Wireshark to decipher. But you are right that we (IETF) really don't need to, and probably shouldn't, worry aobut that, because that is a problem for the SBCs of the world. What we define should actually work in and E2E model with no SBCs rewriting everything along the way. And then that should actually become a usable model for what ought to flow *between* SBCs, so that its not necessary to negotiate n^2 number transformations. But I still have to ask: Why *wouldn't* those using telephone numbers *want* to use TEL URIs for From, To, and P-A-ID headers? This eliminates those domain names that have no relevance to how the URIs are used. Is it simply "we don't do it that way and see no reason to change"? [ [RS> ] Well URI's do have some relevance when you see carriers actually deploying various forms of SIP Interconnection among themselves and the To: and From: in some cases actually identify the underlying carriers after the first order number translation. The preference is always for a fully formed SIP URI vs Tel. That's the way bi lateral NNI agreements are written generally. I will argue rather aggressively that the protocol methodologies for STIR need to be relatively compatible with the number translations for SIP interconnection. I simply can't imagine some new stack in the CSCF's in any existing or future planned 3GPP IMS releases. If anyone has any information to the contrary I'd be very interested to know. Thanks, Paul > Unfortunately there is no solution for this. It's the nature of standards organizations to keep their specs self-consistent, to not change their view unless it can be proven that something's fundamentally broken if their view is followed, to not even be able to change their view unless it can be proven that absolutely no one follows it, etc. > > And the IETF's not alone in having that problem. The 3GPP IMS specs have the same problem - no one actually follows all the specs to-the-letter; not if you look at Wireshark traces. Things would break if they tried to follow them precisely. The same with the specs that many country-specific SDOs generate. > > Thank god we have Wireshark. :) > > -hadriel > > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Fri Jun 21 15:07: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 9981721F9DE8 for ; Fri, 21 Jun 2013 15:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 vJwkgPa-LDYB for ; Fri, 21 Jun 2013 15:07:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97F2021F9DEA for ; Fri, 21 Jun 2013 15:07:20 -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 r5LM7Fgb020775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 15:07:18 -0700 Message-ID: <51C4CE80.40701@dcrocker.net> Date: Fri, 21 Jun 2013 15:06:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 21 Jun 2013 15:07:18 -0700 (PDT) Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band 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: Fri, 21 Jun 2013 22:07:25 -0000 On 6/20/2013 1:49 PM, Peterson, Jon wrote: > Yes, I think there can be differences in how well two mechanisms like this > perform, and I don't think it's ridiculous to propose that we should use a > rely on one when possible, and the other when the first isn't possible. This sort of belts-and-suspenders approach has obvious appeal, for the reason you cite. It also is massively expensive; and it might introduce some problematic interactions between the two. (The cliche "if you have one watch you know what time it is; if you have two, you're never quite sure" comes to mind.) Do you know of any examples of similar functional redundancy for critical infrastructure services on the Internet? I can't think of one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Fri Jun 21 15:10: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 7B4F821F9E74 for ; Fri, 21 Jun 2013 15:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_45=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 kTcmN9xshT5z for ; Fri, 21 Jun 2013 15:10:34 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0462421F9E23 for ; Fri, 21 Jun 2013 15:10:34 -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, 21 Jun 2013 15:10:33 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyA//+U9yA= Date: Fri, 21 Jun 2013 22:10:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0B023@EX2K10MB1.corp.yaanatech.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> In-Reply-To: <51C4C631.2000802@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.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00EE_01CE6EAA.9E08DE00" MIME-Version: 1.0 Cc: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 22:10:38 -0000 ------=_NextPart_000_00EE_01CE6EAA.9E08DE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One might also question if one puts an E.164 number in the context of a domain name, does that rightly or wrongly assert that the number was assigned to that domain? If not belonging to that domain, then that is injecting an error into the system. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, June 21, 2013 5:31 PM To: Hadriel Kaplan Cc: Wendt, Chris; Brian Rosen; Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On 6/21/13 5:11 PM, Hadriel Kaplan wrote: > > On Jun 21, 2013, at 2:52 PM, Paul Kyzivat wrote: > >> On 6/20/13 1:58 PM, Wendt, Chris wrote: >>> No, sorry, actually the complete opposite. Depricate the use of tel >>> uri. only use SIP URI. (you quoted me wrong, didn't say get rid of, >>> I said get away from) >> >> Let me get this straight: >> >> You want to deprecate TEL? >> And you want to not use (deprecate) user=phone? >> And I suppose that also means you don't want to deprecate user=dialstring? >> So I guess you just want to reserve all user parts that are all numeric to mean "some sort of phone number or dial string thing whose syntax is vaguely defined"??? >> Would you allow the use of the telephone-subscriber syntax from the tel URI (with "+", separators, paramters, etc.), or do you want to deprecate that too? > > I think what Chris is saying is that in the real world that's generally the case: TEL URI is rarely seen, the existence or lack thereof for 'user=phone' is ignored, 'user=dialstring' is rarely ever seen, and all user names of digits do in fact require contextual knowledge that does not exist in the URI. > > And the truth is he's right, at least in the majority sense. > > But I think you're also right: in the IETF we can't deprecate or ignore them. We need to have them to make our specs self-consistent, and we don't want to presume a specific deployment model and make different rules for each device in it, and we want it to be possible to handle digit-based usernames with a "do what I say not what I mean" model. Whether they actually can be or not in the real world today doesn't matter - they could be if everyone followed the rules in the RFCs. > > I'm not saying the IETF is wrong to ignore the real world - for one thing there's probably *some* SIP domain of SIP devices somewhere that actually follow the RFCs sufficiently to use that stuff, and for that reason we wouldn't deprecate it; and there are certainly specific SIP hops/devices in general where those rules do apply, and they're doing the "right thing", and for that reason we wouldn't deprecate it as well. > > But for people actually using this stuff - building products, deploying it all, managing the service - for them it's frustrating that the IETF RFCs don't line up with the reality as shown by Wireshark. And this will work for them as long as they live in their sheltered garden, OR, as long as they deploy SBCs at the boundaries of their garden to preserve their naive assumptions. So its no problem for you - its just a way to preserve your business model. :-) But you are right that we (IETF) really don't need to, and probably shouldn't, worry aobut that, because that is a problem for the SBCs of the world. What we define should actually work in and E2E model with no SBCs rewriting everything along the way. And then that should actually become a usable model for what ought to flow *between* SBCs, so that its not necessary to negotiate n^2 number transformations. But I still have to ask: Why *wouldn't* those using telephone numbers *want* to use TEL URIs for From, To, and P-A-ID headers? This eliminates those domain names that have no relevance to how the URIs are used. Is it simply "we don't do it that way and see no reason to change"? Thanks, Paul > Unfortunately there is no solution for this. It's the nature of standards organizations to keep their specs self-consistent, to not change their view unless it can be proven that something's fundamentally broken if their view is followed, to not even be able to change their view unless it can be proven that absolutely no one follows it, etc. > > And the IETF's not alone in having that problem. The 3GPP IMS specs have the same problem - no one actually follows all the specs to-the-letter; not if you look at Wireshark traces. Things would break if they tried to follow them precisely. The same with the specs that many country-specific SDOs generate. > > Thank god we have Wireshark. :) > > -hadriel > > > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00EE_01CE6EAA.9E08DE00 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy MTIyMTAzMVowIwYJKoZIhvcNAQkEMRYEFCRQ9JDqcNA1tBgJrDQbuNLd+aUaMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAHfallHuLaCaG8txQEj8hefgaeRtXapZGCiJMRjhJ ogGC2pMeUKnun8i5lfvt+kuPxMyEB3IhvJUoCzoet2NkJV/PkNWE9R5ZrGji/Gr4rv0LR/cO8cqM c3mZ8XM9mRS2CX/JrYg9OmpTSOY3YDGX13PzuCip8H+yKjAhWf8+sSZO1Tb0ced9gpShQPvXnYrq tXXuHXDER62ZMe/hf93tAzbOJWfEfgLN1Z7srM23WQcowdMbELG6XtKfMvJKBOhN+3zoEfLKEbsk 5JvATTrgCy2a4OIk0l3zgUtcqs26zZZ/1Rdo/WGAcsurNdfTiyhGrShiNYSt523LW9Kjh+V70AAA AAAAAA== ------=_NextPart_000_00EE_01CE6EAA.9E08DE00-- From hadriel.kaplan@oracle.com Fri Jun 21 15:34: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 C83E921F9E8F for ; Fri, 21 Jun 2013 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ce7CUgu6BxHN for ; Fri, 21 Jun 2013 15:34:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4239921F9E89 for ; Fri, 21 Jun 2013 15:34:03 -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 r5LMXwHu011004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 22:33:59 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 r5LMXuYU010593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 22:33:57 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5LMXuZa014183; Fri, 21 Jun 2013 22:33:56 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jun 2013 15:33:56 -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: <51C4C631.2000802@alum.mit.edu> Date: Fri, 21 Jun 2013 18:33:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Wendt, Chris" , "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 21 Jun 2013 22:34:09 -0000 On Jun 21, 2013, at 5:31 PM, Paul Kyzivat wrote: > And this will work for them as long as they live in their sheltered = garden, Ironically, it is the IETF that lives in a sheltered garden. A = virtual-reality one. I like that garden - it's very comforting to only see neat rows of = beautiful plants and trees growing as you programmed them to. It's much less fun to be in the real world with bugs and weeds and = thorns, and plants trying to grow as they wish. > OR, as long as they deploy SBCs at the boundaries of their garden to = preserve their naive assumptions. > So its no problem for you - its just a way to preserve your business = model. :-) You've known me and my efforts in the IETF have actually been the exact = opposite. That I've tried time and again to make things more = interoperable, less complicated, and with a desire that SBCs *not* have = to fix them. That's why I spend time in the IETF - its not my day job. = If my goal was to have interop problems for SBCs to fix, I would leave = the IETF alone and let it accomplish that goal for me. > But I still have to ask: >=20 > Why *wouldn't* those using telephone numbers *want* to use TEL URIs = for From, To, and P-A-ID headers? This eliminates those domain names = that have no relevance to how the URIs are used. Is it simply "we don't = do it that way and see no reason to change"? There are actually several reasons, and we've talked about them before = in SIP or SIPPING lists years back. But it doesn't matter because it's = too late now. There's too much stuff deployed that doesn't support = them. And as I said you *will* certainly see TEL URIs on specific SIP = hops, but they're converted to/from SIP URIs on each end of the hop. = (e.g., on some inter-carrier SIP peering connections this happens) -hadriel From pkyzivat@alum.mit.edu Fri Jun 21 19: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 D36C721E80A7 for ; Fri, 21 Jun 2013 19:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWc9y14RwvaE for ; Fri, 21 Jun 2013 19:36:35 -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 DF2F421F9A7E for ; Fri, 21 Jun 2013 19:36:34 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id rEZi1l0081ei1Bg51EcZoC; Sat, 22 Jun 2013 02:36:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id rEcZ1l00C3ZTu2S3kEcZNA; Sat, 22 Jun 2013 02:36:33 +0000 Message-ID: <51C50DAF.40006@alum.mit.edu> Date: Fri, 21 Jun 2013 22:36:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> In-Reply-To: <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@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=1371868593; bh=Y3FqjxJA0E4JP9VAHQGqHzY0qVHb+y+qWR8gaInBSPE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jsDIhnWp9WwT00vQuu3NUkkNV69hVa/HNBq9691fb+vmdAmsYGbNH7mg2ptU7hJT7 WLGwq5RGBhmOOgUfnrewGXVx+dclYgA544Na5xrUjU6phM3sFl4T0n3dsG5Cyj6P6+ EgJkZRfL+fK6qeOyCrlp4JOhWKnUzvGwSPKOJJhIoxfSyyURCI/EJEjO0NCIwJXNA1 km1VuTNGlkX4KMCwlyWUKNrqRF1cN6Bol83qMfOLE8FktskeBzTcJAW33VseArsokx tr+4Y4emOPMS7xdXE1tISnpBonffB6Sb/mIyZHYyXYGS+B8xbJlOJu1Z+dZD4qJv87 HpfveVQ2OMiKw== Cc: "Wendt, Chris" , "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 02:36:40 -0000 Don't you find it rather silly and unfortunate that we have to rewrite all of the URIs in the message over and over as it transits the network, rather than using a context-free form that doesn't need to be rewritten? Of course this is for the most part irrelevant *to stir*, *except* for whatever is used to sign the message. But it isn't going to work if the recipient of a request has to use the originator's local context to canonicalize the caller phone number in order to check the signature. Thanks, Paul On 6/21/13 6:33 PM, Hadriel Kaplan wrote: > > On Jun 21, 2013, at 5:31 PM, Paul Kyzivat wrote: > >> And this will work for them as long as they live in their sheltered garden, > > Ironically, it is the IETF that lives in a sheltered garden. A virtual-reality one. > I like that garden - it's very comforting to only see neat rows of beautiful plants and trees growing as you programmed them to. > It's much less fun to be in the real world with bugs and weeds and thorns, and plants trying to grow as they wish. > > >> OR, as long as they deploy SBCs at the boundaries of their garden to preserve their naive assumptions. >> So its no problem for you - its just a way to preserve your business model. :-) > > You've known me and my efforts in the IETF have actually been the exact opposite. That I've tried time and again to make things more interoperable, less complicated, and with a desire that SBCs *not* have to fix them. That's why I spend time in the IETF - its not my day job. If my goal was to have interop problems for SBCs to fix, I would leave the IETF alone and let it accomplish that goal for me. > > >> But I still have to ask: >> >> Why *wouldn't* those using telephone numbers *want* to use TEL URIs for From, To, and P-A-ID headers? This eliminates those domain names that have no relevance to how the URIs are used. Is it simply "we don't do it that way and see no reason to change"? > > There are actually several reasons, and we've talked about them before in SIP or SIPPING lists years back. But it doesn't matter because it's too late now. There's too much stuff deployed that doesn't support them. And as I said you *will* certainly see TEL URIs on specific SIP hops, but they're converted to/from SIP URIs on each end of the hop. (e.g., on some inter-carrier SIP peering connections this happens) > > -hadriel > > From hadriel.kaplan@oracle.com Sat Jun 22 00:02: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 8D06B21F9DB2 for ; Sat, 22 Jun 2013 00:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 wdU6jWUowOL5 for ; Sat, 22 Jun 2013 00:02:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E8D8221F9D4B for ; Sat, 22 Jun 2013 00:02:17 -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 r5M6tstM021188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jun 2013 06:55:55 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 r5M72AVE009946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jun 2013 07:02:11 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 r5M72AMD021212; Sat, 22 Jun 2013 07:02:10 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-217.vpn.oracle.com (/10.154.182.217) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Jun 2013 00:02: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: <51C50DAF.40006@alum.mit.edu> Date: Sat, 22 Jun 2013 03:02:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Wendt, Chris" , Brian Rosen , "" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 07:02:24 -0000 On Jun 21, 2013, at 10:36 PM, Paul Kyzivat = wrote: > Don't you find it rather silly and unfortunate that we have to rewrite = all of the URIs in the message over and over as it transits the network, = rather than using a context-free form that doesn't need to be rewritten? Yup. Used to drives me nuts, because it requires a lot of configuration = in a lot of systems. But there're too many servers/phones/gateways/etc. = where each vendor can only send/receive one format/schema, without = something in common for them all. And when carriers provide SIP trunks to Enterprise customers, there's = already a PBX in the Enterprise and it does whatever format works for = it, so the carrier can't make them change. And when they peer with = other carriers they can't make the other carriers change. It's a = quagmire. So I decided to "just let go Luke" and let The Force guide me to things = I have a chance of improving. :) > Of course this is for the most part irrelevant *to stir*, *except* for = whatever is used to sign the message. But it isn't going to work if the = recipient of a request has to use the originator's local context to = canonicalize the caller phone number in order to check the signature. Well... I think it might actually work. I mean yes - each domain has = its own context for usernames - but they do actually know what the E.164 = number is for that username in *their* context. (if the username could = even be an E.164 at all - i.e., if it's not a short code or some other = digit string that really doesn't represent an E.164 number) =20 In other words, if you were to capture a SIP message with wireshark and = show it to the operator who sent it, they could look at it and tell you = what its full E.164 number is, even without having to look up a = translation database or anything. Because it invariably follows a = pattern of some type for their network. It may not be a trivial = pattern, and it may have conditional rules, but it's a pattern. And the = pattern may look different in different spots of their network, but at = any given point they'd know what pattern it follows there and how to = turn it into an E.164 number. So for the systems they use to sign the caller-id, they'll know what the = pattern is at that point and can configure the system appropriately to = internally generate the E.164 based on the pattern in order to sign it. = And the same goes for the verifier - wherever the verifying system is in = the terminating domain, it too knows what it's locally-specific pattern = is and it can determine the E.164 that was signed. It sucks to have to do it this way. It will take configuration on the = signer/verifier systems. I hate having to do things by configuration = instead of automatically. It's more work for the admin, and mistakes = can cause hard-to-find errors, and it's brittle. But I don't see a way = around it for this STIR stuff, and it will work in the end. I'm also thinking that we might want to consider copying these generated = To/=46rom canonical E.164 numbers into the Identity header - not the = whole URIs, just the digits without any decoration, in a header param. = They wouldn't be used for caller-id displaying, nor routing, nor = anything at a SIP layer. They're to help with troubleshooting if the = signature failed. They wouldn't be covered by the signature hash, and = they could even be optional to send. Good-idea/bad-idea? -hadriel From pkyzivat@alum.mit.edu Sat Jun 22 06: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 8D9F521E809A for ; Sat, 22 Jun 2013 06:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.122, 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 MxXoM7mfDTat for ; Sat, 22 Jun 2013 06:25:37 -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 93E8711E80F8 for ; Sat, 22 Jun 2013 06:25:37 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id rQWx1l0030QuhwU5FRRbPY; Sat, 22 Jun 2013 13:25:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id rRRa1l00Y3ZTu2S3NRRahY; Sat, 22 Jun 2013 13:25:35 +0000 Message-ID: <51C5A5CE.2050906@alum.mit.edu> Date: Sat, 22 Jun 2013 09:25:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> In-Reply-To: <39DAF034-BC69-44A0-9034-D646AFC50283@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=1371907535; bh=qeeZVu0anA8P9T/A6aZqSQ6XUuSeZD6IhzIKs+nV0u4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JMC/aAuyRh3YgWCUwO1Uy3wYdA97mvdmpuucVRfQSceoM2ii0PxtPaRvlyLqogeL0 jyS79uN7ErQb2oTgj6QYbnCGUZAI9JPPphg+2DQBzq96mTbJr9uPr7KGuVFhuUgWfN Oeco94a3jdePIAOp+sDTS9S49YpTjuaIIn7BTm2ymG324iMPGYA6ja0x7eepJtyV3t AoZbNXOgbysBsDXQ18nggCypAwJ34pzIH3AFQMiJN9v95b4UkekrEl2wN/zZVYdmZR FGaGNt1BZ8TjHJRo6erKyaXqUt0nImtOsv40HGIGFPyWX5fa5DFOjAXjj11v5F1C53 DBDXtnSmKt+Mg== Cc: "Wendt, Chris" , Brian Rosen , "" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 13:25:43 -0000 On 6/22/13 3:02 AM, Hadriel Kaplan wrote: >> Of course this is for the most part irrelevant *to stir*, *except* for whatever is used to sign the message. But it isn't going to work if the recipient of a request has to use the originator's local context to canonicalize the caller phone number in order to check the signature. > > Well... I think it might actually work. I mean yes - each domain has its own context for usernames - but they do actually know what the E.164 number is for that username in *their* context. (if the username could even be an E.164 at all - i.e., if it's not a short code or some other digit string that really doesn't represent an E.164 number) > > In other words, if you were to capture a SIP message with wireshark and show it to the operator who sent it, they could look at it and tell you what its full E.164 number is, even without having to look up a translation database or anything. Because it invariably follows a pattern of some type for their network. It may not be a trivial pattern, and it may have conditional rules, but it's a pattern. And the pattern may look different in different spots of their network, but at any given point they'd know what pattern it follows there and how to turn it into an E.164 number. > > So for the systems they use to sign the caller-id, they'll know what the pattern is at that point and can configure the system appropriately to internally generate the E.164 based on the pattern in order to sign it. And the same goes for the verifier - wherever the verifying system is in the terminating domain, it too knows what it's locally-specific pattern is and it can determine the E.164 that was signed. > > It sucks to have to do it this way. It will take configuration on the signer/verifier systems. I hate having to do things by configuration instead of automatically. It's more work for the admin, and mistakes can cause hard-to-find errors, and it's brittle. But I don't see a way around it for this STIR stuff, and it will work in the end. > > I'm also thinking that we might want to consider copying these generated To/From canonical E.164 numbers into the Identity header - not the whole URIs, just the digits without any decoration, in a header param. They wouldn't be used for caller-id displaying, nor routing, nor anything at a SIP layer. They're to help with troubleshooting if the signature failed. They wouldn't be covered by the signature hash, and they could even be optional to send. Good-idea/bad-idea? You seem to be missing the point above: *Of course* the sending operator (signer) can look at the original message and figure out what the corresponding E.164 is for the caller, and probably for the callee too. And so can use those to sign the message. And presumably the verifier will be able to look at the received message and be able to figure out the E.164 number for the recipient, since it knows where it is going to be received. But it is far from clear that the verifier will be able to look at the received message and be able to figure out the E.164 number for the caller. It may just see a localized form of that number that is meaningful in the caller's context. And without being familiar with the caller's context that isn't enough. STIR *could* make an assumption (requirement?) that whatever value is used be rewritten along the path from signer to verifier so that the verifier will be able to do the verification. But if that is the intent, then it had better be stated with great clarity. But I continue to find this rediculous - to depend on constant rewriting throughout the path of the message rather than canonicalizing at the endpoints. It is the antithesis of the E2E principal. (But as a precedent, it is exactly analogous to what NATs do.) Thanks, Paul From hadriel.kaplan@oracle.com Sat Jun 22 12:45: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 974C521F9F07 for ; Sat, 22 Jun 2013 12:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 2AsLDxikxIQz for ; Sat, 22 Jun 2013 12:45:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C063321F9F0E for ; Sat, 22 Jun 2013 12:45:01 -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 r5MJitls018737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jun 2013 19:44:56 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 r5MJisww022256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jun 2013 19:44: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 r5MJisn1022249; Sat, 22 Jun 2013 19:44:54 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-161-7.vpn.oracle.com (/10.154.161.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Jun 2013 12:44:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C4BBD4.5030208@alum.mit.edu> Date: Sat, 22 Jun 2013 15:44:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> <51C4BBD4.5030208@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] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 19:45:09 -0000 On Jun 21, 2013, at 4:47 PM, Paul Kyzivat wrote: > On 6/20/13 3:46 PM, Hadriel Kaplan wrote: >=20 >> And there's no "new" money for this - this stuff doesn't create a new = revenue-generating feature, nor a feature one can use for competitive = advantage. This thing is just a cost sink: another red line item for = opex and capex, with no black line to offset it. It's got to be as = cheap as possible. And it's got to be something we think will actually = *work*. We can be wrong in the end of course, but we can't believe = we'll be wrong from the start! >=20 > What about the $5/month fee for "block spam calls"? :-) I can't tell if you were being serious or not, so I'll reply in case you = are. :) Having a validated Caller-ID doesn't block spam calls. It just reduces = them, by removing the ones with spoofed caller-ids. Just like I get = tons of email spam from perfectly legitimate email addresses. Would you = pay $5/month for something that didn't actually block the spam calls? = We're already supposed to get do-not-call listing for free, and arguably = beyond that it's hard to determine what is really spam vs. legitimate = bulk-calling. Would you pay $5/month for "no spoofed caller-ids" - i.e., just for = legitimate caller-ids? My guess is most every-day users expect they're = already getting that, and that it's part of the service. But having said that, it's definitely possible that certain corporations = or organizations would pay for "verified" caller-ids. So there probably = will be some new revenue for some carriers for a time. But for such a = thing to work, it would require most numbers to be verifiable, which = means most carriers doing it, which means most calls will be verifiable = for everyone anyway, which means ultimately it won't be worth much to = get what everyone else gets for free as part of their phone service. -hadriel From md3135@att.com Sat Jun 22 13:15: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 4E76321F9C1B for ; Sat, 22 Jun 2013 13:15:26 -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 dt3RWFy46qkA for ; Sat, 22 Jun 2013 13:15:20 -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 7A7B521F9C46 for ; Sat, 22 Jun 2013 13:15:20 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8d506c15.69e54940.2766754.00-570.7685982.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 22 Jun 2013 20:15:20 +0000 (UTC) X-MXL-Hash: 51c605d81c24bee9-dfd06b777d2587bc1e5e6fe75e9aba403e0e957a Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6d506c15.0.2766752.00-401.7685970.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 22 Jun 2013 20:15:19 +0000 (UTC) X-MXL-Hash: 51c605d75f873b58-fec49c782d1ec957f6862b9d150d4c8b0d0c0bdd 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 r5MKFIf9016793; Sat, 22 Jun 2013 16:15:18 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5MKFAqW016730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jun 2013 16:15:12 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 22 Jun 2013 20:14:58 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Sat, 22 Jun 2013 16:15:06 -0400 From: "DOLLY, MARTIN C" To: Hadriel Kaplan Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHOb4D39du0y+uG9k2ZHUL5WU/0mZlCK11M Date: Sat, 22 Jun 2013 20:15:05 +0000 Message-ID: <470A636B-5F07-4999-B7A3-7EEE46A9708C@att.com> References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> <51C4BBD4.5030208@alum.mit.edu>, <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> In-Reply-To: <4535B4B3-7149-4D5F-8838-A6B3563ED795@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 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=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=yPCof4Zb] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=6bnBPUf0-yF89YNJxugA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=7DSvI1NPTFQA:10 a=lZB815dzVvQA:10 a=Rl4pAcGy6vk] X-AnalysisOut: [yZUfz:21 a=BfhExpRlURKTkwyX:21] Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 20:15:26 -0000 Unless the FCC always the carriers to block calls, the best that may be don= e is displaying the CgPN as verified=20 Note there may be legitimate calls that are not verified=20 Martin Dolly AT&T=20 Sent from my iPhone On Jun 22, 2013, at 3:45 PM, "Hadriel Kaplan" w= rote: >=20 > On Jun 21, 2013, at 4:47 PM, Paul Kyzivat wrote: >=20 >> On 6/20/13 3:46 PM, Hadriel Kaplan wrote: >>=20 >>> And there's no "new" money for this - this stuff doesn't create a new r= evenue-generating feature, nor a feature one can use for competitive advant= age. This thing is just a cost sink: another red line item for opex and ca= pex, with no black line to offset it. It's got to be as cheap as possible.= And it's got to be something we think will actually *work*. We can be wr= ong in the end of course, but we can't believe we'll be wrong from the star= t! >>=20 >> What about the $5/month fee for "block spam calls"? :-) >=20 >=20 > I can't tell if you were being serious or not, so I'll reply in case you = are. :) >=20 > Having a validated Caller-ID doesn't block spam calls. It just reduces = them, by removing the ones with spoofed caller-ids. Just like I get tons o= f email spam from perfectly legitimate email addresses. Would you pay $5/m= onth for something that didn't actually block the spam calls? We're alread= y supposed to get do-not-call listing for free, and arguably beyond that it= 's hard to determine what is really spam vs. legitimate bulk-calling. >=20 > Would you pay $5/month for "no spoofed caller-ids" - i.e., just for legit= imate caller-ids? My guess is most every-day users expect they're already = getting that, and that it's part of the service. >=20 > But having said that, it's definitely possible that certain corporations = or organizations would pay for "verified" caller-ids. So there probably wi= ll be some new revenue for some carriers for a time. But for such a thing = to work, it would require most numbers to be verifiable, which means most c= arriers doing it, which means most calls will be verifiable for everyone an= yway, which means ultimately it won't be worth much to get what everyone el= se gets for free as part of their phone service. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Sat Jun 22 13:30: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 AB42B21F9F1B for ; Sat, 22 Jun 2013 13:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 n9QdsyfPTklT for ; Sat, 22 Jun 2013 13:30:11 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9431021F9EFF for ; Sat, 22 Jun 2013 13:30:10 -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 r5MKNksS026698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jun 2013 20:23:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5MKU2Uv002001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jun 2013 20:30:02 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 r5MKU13X001962; Sat, 22 Jun 2013 20:30:02 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-161-7.vpn.oracle.com (/10.154.161.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Jun 2013 13:30:01 -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: <51C5A5CE.2050906@alum.mit.edu> Date: Sat, 22 Jun 2013 16:30:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Wendt, Chris" , "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 20:30:17 -0000 On Jun 22, 2013, at 9:25 AM, Paul Kyzivat wrote: > *Of course* the sending operator (signer) can look at the original = message and figure out what the corresponding E.164 is for the caller, = and probably for the callee too. And so can use those to sign the = message. >=20 > And presumably the verifier will be able to look at the received = message and be able to figure out the E.164 number for the recipient, = since it knows where it is going to be received. >=20 > But it is far from clear that the verifier will be able to look at the = received message and be able to figure out the E.164 number for the = caller. It may just see a localized form of that number that is = meaningful in the caller's context. And without being familiar with the = caller's context that isn't enough. Ahhh - so what you're saying is that canonicalization will work for the = To-number, but not the From-number. Sorry, missed that point in your = original email. > STIR *could* make an assumption (requirement?) that whatever value is = used be rewritten along the path from signer to verifier so that the = verifier will be able to do the verification. But if that is the intent, = then it had better be stated with great clarity. Right, I think that is a basic assumption and we could even write it in = as a requirement. And it's not as ludicrous as it sounds to do that. = For one thing, afaict it's actually the case today. At least on SBCs, = whenever I've seen rewriting of the To-URI, there's a corresponding = rewrite of the From-URI. In practice, operators of SIP domains do use = the From-URI for stuff, so they rewrite them as they exit/enter domains. But even if it *weren't* the case, that instead a terminating domain = receives a From-URI in a format it can't determine an E.164 for, then it = shouldn't be displaying it as a caller-id on its subscribers' phones. = So if the verification fails or is un-doable due to receiving such an = unknown string, then arguably it's achieving the correct result: the = caller-id is unverified. Obviously at a high-level we don't *want* that = to happen - we want to be able to successfully verify legitimate = caller-ids, because otherwise from the user's perspective it's a = false-positive - but over time those things will sort themselves out. That's why I was wondering if we should put a copy of the E.164 numbers = into the Identity header, to help the operators troubleshoot failures = and sort them out. > But I continue to find this rediculous - to depend on constant = rewriting throughout the path of the message rather than canonicalizing = at the endpoints. It is the antithesis of the E2E principal. (But as a = precedent, it is exactly analogous to what NATs do.) "Endpoints" have rarely ever been able to canonicalize. They have no = knowledge of "contexts", or what is or is not a phone number, or what is = or is not an E.164 number vs. national vs. local vs. short code vs. star = code vs. just a string of digits. All they know is the user pressed = digit buttons and a "call" or "send" button. So they just put those = digits into a SIP To-URI and req-uri user portion. And they put the AoR = they Registered into the From-URI, which again they don't know the = semantics of but just use what they were configured to Register with. Arguably that's one of the reasons few people use 'user=3Dphone' and = Tel-URLs and such, and rewriting happens a lot. The RFCs assumed the = endpoints were smart - that they'd somehow know the intentions of the = human and the contexts of phone numbers, and put the right things in the = To/From. And then we told the Proxies not to change those To/From's, = because doing that was "evil" and subverted the endpoints' intentions. = But in practice the endpoints are dumb and the 'proxies' are smart... at = least for this topic anyway. ;) -hadriel From michael.hammer@yaanatech.com Sat Jun 22 15:01: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 25A6821F9DD6 for ; Sat, 22 Jun 2013 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, 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 gshivyD3bn-q for ; Sat, 22 Jun 2013 15:01:08 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 01E1F21F9D67 for ; Sat, 22 Jun 2013 15:01: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; Sat, 22 Jun 2013 15:01:07 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyAgAARcACAAEPKgIAASjYAgABrIQCAAHaXgP//oHnA Date: Sat, 22 Jun 2013 22:01:05 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com> In-Reply-To: <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@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.17] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01CE6F72.769AE2A0" MIME-Version: 1.0 Cc: "Chris_Wendt@cable.comcast.com" , "br@brianrosen.net" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 22:01:12 -0000 ------=_NextPart_000_0023_01CE6F72.769AE2A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Those who mangle the To and From headers tend to be the sort that are too clever for their own good. They tend to be of the hop-by-hop mind-set and don't quite get the E2E idea of SIP. Note: Vendors can modify node behavior to do what is "right". The existing code base is flexible; it is software after all. The hard part is getting industry consensus on what is "right". Don't underestimate the client, PBX, or SBC vendors ability to adapt. It might be best to leave the Request-URI, To-, and Route- headers to be mangled, and not confuse that with the source identity problem. If we limited that scope, it might help keep this from trying to boil the ocean. The tendency of folks to get too creative is what usually leads to regulation. In this case, it may come to the FCC establishing rules for those that get number assignments directly to enforce. We should also not conflate the technical detail of ensuring validated numbers in the signaling and the legal distinction of what is spam or not. Thanks to our legislators and the various loop-holes (political calls anyone?) that could change, we have no control of the latter, but might be able to help with the former. Also, as noted already, there may be cases where it is permissible to send anonymous calls that might be dependent on the called party identity, but that is an exception that should not be too hard to handle, once the basic rules are established. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, June 22, 2013 4:30 PM To: Paul Kyzivat Cc: Wendt, Chris; ; Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 22, 2013, at 9:25 AM, Paul Kyzivat wrote: > *Of course* the sending operator (signer) can look at the original message and figure out what the corresponding E.164 is for the caller, and probably for the callee too. And so can use those to sign the message. > > And presumably the verifier will be able to look at the received message and be able to figure out the E.164 number for the recipient, since it knows where it is going to be received. > > But it is far from clear that the verifier will be able to look at the received message and be able to figure out the E.164 number for the caller. It may just see a localized form of that number that is meaningful in the caller's context. And without being familiar with the caller's context that isn't enough. Ahhh - so what you're saying is that canonicalization will work for the To-number, but not the From-number. Sorry, missed that point in your original email. > STIR *could* make an assumption (requirement?) that whatever value is used be rewritten along the path from signer to verifier so that the verifier will be able to do the verification. But if that is the intent, then it had better be stated with great clarity. Right, I think that is a basic assumption and we could even write it in as a requirement. And it's not as ludicrous as it sounds to do that. For one thing, afaict it's actually the case today. At least on SBCs, whenever I've seen rewriting of the To-URI, there's a corresponding rewrite of the From-URI. In practice, operators of SIP domains do use the From-URI for stuff, so they rewrite them as they exit/enter domains. But even if it *weren't* the case, that instead a terminating domain receives a From-URI in a format it can't determine an E.164 for, then it shouldn't be displaying it as a caller-id on its subscribers' phones. So if the verification fails or is un-doable due to receiving such an unknown string, then arguably it's achieving the correct result: the caller-id is unverified. Obviously at a high-level we don't *want* that to happen - we want to be able to successfully verify legitimate caller-ids, because otherwise from the user's perspective it's a false-positive - but over time those things will sort themselves out. That's why I was wondering if we should put a copy of the E.164 numbers into the Identity header, to help the operators troubleshoot failures and sort them out. > But I continue to find this rediculous - to depend on constant rewriting throughout the path of the message rather than canonicalizing at the endpoints. It is the antithesis of the E2E principal. (But as a precedent, it is exactly analogous to what NATs do.) "Endpoints" have rarely ever been able to canonicalize. They have no knowledge of "contexts", or what is or is not a phone number, or what is or is not an E.164 number vs. national vs. local vs. short code vs. star code vs. just a string of digits. All they know is the user pressed digit buttons and a "call" or "send" button. So they just put those digits into a SIP To-URI and req-uri user portion. And they put the AoR they Registered into the From-URI, which again they don't know the semantics of but just use what they were configured to Register with. Arguably that's one of the reasons few people use 'user=phone' and Tel-URLs and such, and rewriting happens a lot. The RFCs assumed the endpoints were smart - that they'd somehow know the intentions of the human and the contexts of phone numbers, and put the right things in the To/From. And then we told the Proxies not to change those To/From's, because doing that was "evil" and subverted the endpoints' intentions. But in practice the endpoints are dumb and the 'proxies' are smart... at least for this topic anyway. ;) -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0023_01CE6F72.769AE2A0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy MjIyMDEwNFowIwYJKoZIhvcNAQkEMRYEFJ5cL2JDhJULKUdtBOPMuN5zk5+HMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAgwUcf9hraPvdQpD4++iLasatn2dPxTi312lKBPRz 2jWnswGchq/rmt4x7a/zYD2b435ixjDH64bYoa9MaOrDpIjD1rIERd2+0hAbaVac7VRhsHyClgV5 ut4wbDtQpugQtv69ADvWyNO5Rp1BbkPHYoKVeusvzGUM6w/HzUBLrzQdixiaR93UUTvSDYipCP4p hTEtIs92BjolR1PgPNUO+bNjPjylzChZddSK5VDfHB400ZCiZoTXO4HcGQEUyL//9J+D3timKKbx yk8epqDpDckP7dEvbQxYSBKyGEqPna6A8brTDWnUckzCWTefwpNVW0IEZTwMbAGobchpeqb6yAAA AAAAAA== ------=_NextPart_000_0023_01CE6F72.769AE2A0-- From hadriel.kaplan@oracle.com Sat Jun 22 18:31: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 8DA0B21F9EBE for ; Sat, 22 Jun 2013 18:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 Df+GOYj9Rk6s for ; Sat, 22 Jun 2013 18:31:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8921F9E82 for ; Sat, 22 Jun 2013 18:31:08 -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 r5N1OiM3011167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Jun 2013 01:24:45 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 r5N1V0ZD026501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Jun 2013 01:31:01 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 r5N1V0Dm026485; Sun, 23 Jun 2013 01:31:00 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-161-7.vpn.oracle.com (/10.154.161.7) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Jun 2013 18:30:59 -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: <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> Date: Sat, 22 Jun 2013 21:31:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31ACB2DE-0B35-4694-947F-8767C22314F4@oracle.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! ! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "pkyzivat@alum.mit.edu" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jun 2013 01:31:14 -0000 On Jun 22, 2013, at 6:01 PM, Michael Hammer = wrote: > Those who mangle the To and =46rom headers tend to be the sort that = are too > clever for their own good. Umm... you mean the sort that want the calls to work? ;) > They tend to be of the hop-by-hop mind-set and don't quite get the E2E = idea > of SIP. It *is* end-to-end - the rewriting is done by B2BUAs, so it's just a lot = of ends. :) And to be fair, it's not every hop/node that rewrites this stuff. = Usually a given domain follows a consistent format/pattern/rule-set = inside its domain, as much as possible. > Note: Vendors can modify node behavior to do what is "right". The = existing > code base is flexible; it is software after all. > The hard part is getting industry consensus on what is "right". Don't > underestimate the client, PBX, or SBC vendors ability to adapt. It is shockingly difficult to get vendors to change software code. Even = if you get them to agree to do it, it takes a surprisingly long time. = Besides, the motivation is backwards - the installed base has already = sold their products and it's working, the new ones are the ones with = motivation to adapt to the installed base, and that means the next round = of new ones have that too, ad infinitum. And when you're a carrier, = your motivation is to add sip trunks from every Enterprise, so you = generally don't tell them to go switch their gear out. Likewise when = peering with another carrier. Changing the To/=46rom URI model in a SIP domain is not a small thing - = it affects almost every SIP system in the domain, not to mention the = back-office stuff (which is a lot of stuff). It's kinda like changing = an ISP network from IPv4 to IPv6. -hadriel From fas_vm@surguttel.ru Sun Jun 23 05:07: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 42E1021F9D81 for ; Sun, 23 Jun 2013 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, 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 Ct8XC9o4kBEA for ; Sun, 23 Jun 2013 05:07:07 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13BFC21F9D7B for ; Sun, 23 Jun 2013 05:07:07 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 9D5CB513846; Sun, 23 Jun 2013 18:06:14 +0600 (YEKT) Received: from Gateway (unknown [151.252.65.251]) by mail.s86.ru (Postfix) with ESMTPA id D4B8651381C; Sun, 23 Jun 2013 18:06:10 +0600 (YEKT) Message-ID: <0D0B90C5B3644827B2C59EE921BCEEFF@Gateway> From: "Anton Tveretin" To: "Hadriel Kaplan" References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net><8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com><988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com><51C4BBD4.5030208@alum.mit.edu> <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> Date: Sun, 23 Jun 2013 18:00:08 +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 130623-1, 23.06.2013), Outbound message X-Antivirus-Status: Clean Cc: stir@ietf.org, "\"Paul Kyzivat\"" Subject: Re: [stir] Out-of-band vs. in-band; basics X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jun 2013 12:07:13 -0000 I agree with that. Validating the sender or caller does not stop spam completely. However, it could be enforceable to mark spam as such (there were ideas for e-mail, as start the subject line from $$$ AFAIK). It would be possible to block spammers who violate a convention. And pay $5/month for no spam at all, I think some businesses would buy it. Someone would prefer spam. ----- Original Message ----- From: "Hadriel Kaplan" To: "Paul Kyzivat" Cc: Sent: Sunday, June 23, 2013 1:44 AM Subject: Re: [stir] Out-of-band vs. in-band On Jun 21, 2013, at 4:47 PM, Paul Kyzivat wrote: > On 6/20/13 3:46 PM, Hadriel Kaplan wrote: > >> And there's no "new" money for this - this stuff doesn't create a new >> revenue-generating feature, nor a feature one can use for competitive >> advantage. This thing is just a cost sink: another red line item for >> opex and capex, with no black line to offset it. It's got to be as cheap >> as possible. And it's got to be something we think will actually *work*. >> We can be wrong in the end of course, but we can't believe we'll be wrong >> from the start! > > What about the $5/month fee for "block spam calls"? :-) I can't tell if you were being serious or not, so I'll reply in case you are. :) Having a validated Caller-ID doesn't block spam calls. It just reduces them, by removing the ones with spoofed caller-ids. Just like I get tons of email spam from perfectly legitimate email addresses. Would you pay $5/month for something that didn't actually block the spam calls? We're already supposed to get do-not-call listing for free, and arguably beyond that it's hard to determine what is really spam vs. legitimate bulk-calling. Would you pay $5/month for "no spoofed caller-ids" - i.e., just for legitimate caller-ids? My guess is most every-day users expect they're already getting that, and that it's part of the service. But having said that, it's definitely possible that certain corporations or organizations would pay for "verified" caller-ids. So there probably will be some new revenue for some carriers for a time. But for such a thing to work, it would require most numbers to be verifiable, which means most carriers doing it, which means most calls will be verifiable for everyone anyway, which means ultimately it won't be worth much to get what everyone else gets for free as part of their phone service. -hadriel From hadriel.kaplan@oracle.com Sun Jun 23 05:33: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 4DDDE21F9AFF for ; Sun, 23 Jun 2013 05:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 LwNRSe34j698 for ; Sun, 23 Jun 2013 05:33:24 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5221F9C71 for ; Sun, 23 Jun 2013 05:33:24 -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 r5NCXJ38004594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Jun 2013 12:33:20 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 r5NCXJwO018933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Jun 2013 12:33:19 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 r5NCXII2018927; Sun, 23 Jun 2013 12:33:18 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-169-233.vpn.oracle.com (/10.154.169.233) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Jun 2013 05:33:18 -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: <0D0B90C5B3644827B2C59EE921BCEEFF@Gateway> Date: Sun, 23 Jun 2013 08:33:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net><8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com><988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com><51C4BBD4.5030208@alum.mit.edu> <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> <0D0B90C5B3644827B2C59EE921BCEEFF@Gateway> To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: stir@ietf.org, "\"Paul Kyzivat\"" Subject: Re: [stir] Out-of-band vs. in-band; basics X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 23 Jun 2013 12:33:31 -0000 On Jun 23, 2013, at 8:00 AM, Anton Tveretin wrote: > I agree with that. Validating the sender or caller does not stop spam = completely. However, it could be enforceable to mark spam as such (there = were ideas for e-mail, as start the subject line from $$$ AFAIK). It = would be possible to block spammers who violate a convention. And pay = $5/month for no spam at all, I think some businesses would buy it. = Someone would prefer spam. There would also be companies willing to pay a lot more than $5/month to = have the calls they make to everyone else *not* be treated as spam. But = undoubtedly many of those companies would be what you and I would = consider to be spammers. ;) -hadriel From dhc@dcrocker.net Sun Jun 23 15:36: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 1168521F915B for ; Sun, 23 Jun 2013 15:36:32 -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 zzyQXQm+Disl for ; Sun, 23 Jun 2013 15:36:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 235EE21F919D for ; Sun, 23 Jun 2013 15:36:26 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5NMaI0W018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Jun 2013 15:36:22 -0700 Message-ID: <51C77861.8090207@dcrocker.net> Date: Sun, 23 Jun 2013 15:36:17 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net><8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com><988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com><51C4BBD4.5030208@alum.mit.edu> <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> <0D0B90C5B3644827B2C59EE921BCEEFF@Gateway> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 23 Jun 2013 15:36:24 -0700 (PDT) Cc: stir@ietf.org, Anton Tveretin , Paul Kyzivat Subject: [stir] trust vs. mistrust (was Re: Out-of-band vs. in-band; basics) 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: Sun, 23 Jun 2013 22:36:32 -0000 On 6/23/2013 5:33 AM, Hadriel Kaplan wrote: > > On Jun 23, 2013, at 8:00 AM, Anton Tveretin wrote: > >> I agree with that. Validating the sender or caller does not stop spam completely. However, it could be enforceable to mark spam as such (there were ideas for e-mail, as start the subject line from $$$ AFAIK). It would be possible to block spammers who violate a convention. And pay $5/month for no spam at all, I think some businesses would buy it. Someone would prefer spam. > > There would also be companies willing to pay a lot more than $5/month to have the calls they make to everyone else *not* be treated as spam. But undoubtedly many of those companies would be what you and I would consider to be spammers. ;) This highlights a classic point of distinction that has proved very difficult for workers in the field to maintain in the email anti-spam world, and I'd expect the same to apply for the SIP world: Everyone working in that space has been forced for nearly 20 years to focus on finding bad messages and obviously without the cooperation of the author. In other words, to focus on the mis-trust side of the equation. Adding authentication creates a collaborative exchange between origination and destination, with a mechanism that is inherently tailored for building trust, finding /good/ messages. In some scenarios, there is a derivative ability to find wayward message, but it really is a secondary benefit of the approach. One of the benefits of the trust side is that it's noise-free, whereas the mistrust side is massively noisy. Noise-free means that you can believe /all/ the data you have for building a reputation on the identifier. When the data are very noisy, you've no clean way to know what to use for reputation and what not to. The trick for getting the trust side to work is building receive-side mechanisms that behave differently when they know they know who originated the contact and know that they are a good actor. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From chris_wendt@cable.comcast.com Sun Jun 23 19:26: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 DFE7F21F95D7 for ; Sun, 23 Jun 2013 19:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 n5AUstMN4wpK for ; Sun, 23 Jun 2013 19:26:40 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4926221F9631 for ; Sun, 23 Jun 2013 19:26:40 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78877743; Sun, 23 Jun 2013 20:25:47 -0600 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sun, 23 Jun 2013 22:26:34 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Sun, 23 Jun 2013 22:26:34 -0400 From: "Wendt, Chris" To: Paul Kyzivat Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd/DYG9JHkYsaU+vynseyHv19w== Date: Mon, 24 Jun 2013 02:26:33 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> In-Reply-To: <51C4A0D6.1000903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <43ABFEE74EA80D48B8516DA19DAD5CA1@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 02:26:47 -0000 >=20 > In that hypothetical world, is there any significance to the domain name = in the URI? Are you in any way obligated to honor it when routing? >=20 If I were to have my way, domain would be representation of the TN owners a= ssertion. Signing of the SIP URI would prove that ownership and that's wha= t goes to the heart of what I believe we want to accomplish in this group. So, yes I believe domain has everything to do with verification and tracabi= lity of the caller-id (and yes the future of SIP peering and call routing = too) -Chris From pkyzivat@alum.mit.edu Sun Jun 23 20:07: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 0909321F998D for ; Sun, 23 Jun 2013 20:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.120, 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 RRr1UOy8zOuZ for ; Sun, 23 Jun 2013 20:07:20 -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 0187321F92E7 for ; Sun, 23 Jun 2013 20:07:19 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id s2zC1l0010QuhwU5937KKh; Mon, 24 Jun 2013 03:07:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id s37J1l00m3ZTu2S3N37KvH; Mon, 24 Jun 2013 03:07:19 +0000 Message-ID: <51C7B7E6.5010100@alum.mit.edu> Date: Sun, 23 Jun 2013 23:07:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Wendt, Chris" References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> In-Reply-To: <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.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=1372043239; bh=Tuw/j4NzTwB7gaTE89GXpDwcmVbyC0F123k/FPASnfA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mk5tBXvjp0XuwCoa/Me/tgwbkGRBXT8ZtAID6DwNr9mpyYesjsMVaWZxLEtLkXkTB R0dkrANRRDEoQuigQiCUgjFsJnX0osWa5udaCrYwTa//yEnOAd/Uvy9QoU2fAyrvqT 1fG8GAYdX7e+P/J9yz8o/Q0xlWzECF9eZ8+47+J12P18a4DjQeS/e8RUOTie3F/+YF JYNvciQa1L8Hv1+BFxyy1TGzYg+V3SzwlJFkJSo7SB+fG/8mmHgJqEj0AbOBMAYjJ7 i0GgKRCNuzYZhTD4eo+DeIeh3AutXc1j/frj5RWfCD4FBYE0yDzGhA9/WKDtQMfpY9 STDBP+Sn7nKZQ== Cc: "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 03:07:26 -0000 On 6/23/13 10:26 PM, Wendt, Chris wrote: >> >> In that hypothetical world, is there any significance to the domain name in the URI? Are you in any way obligated to honor it when routing? >> > > If I were to have my way, domain would be representation of the TN owners assertion. Signing of the SIP URI would prove that ownership and that's what goes to the heart of what I believe we want to accomplish in this group. > > So, yes I believe domain has everything to do with verification and tracability of the caller-id (and yes the future of SIP peering and call routing too) I don't follow you. Consider a UA that is sending a request. It is given a phone number by the caller. A priori it doesn't know the domain name that owns the phone number. Yet it needs to form some sort of request in order to send the request. So what domain name does it use? Then when the request is routed, is the request routed based on the domain name, or the number? For example, the originating UA may insert some domain, then route to its outbound proxy, independent of either domain or number. That UA may have made the domain correspond to the domain of its provider, or not. When the request reaches the outbound proxy, belonging to the caller's provider, if the domain of the r-uri is that of the provider, then of course it makes sense for the proxy to route the request further based on the number. But if the r-uri does *not* contain the domain of the provider, what shall the proxy do? Should it honor the uri, and route based on domain? Or may it simply ignore the domain, translate the the r-uri based on the number and route it on based on that? IMO, in the latter case it is obligated to route based on the domain of the r-uri. Thanks, Paul From chris_wendt@cable.comcast.com Sun Jun 23 20:17: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 B326221F9815 for ; Sun, 23 Jun 2013 20:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=-1.686, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4Nv3dt0lqUa for ; Sun, 23 Jun 2013 20:16:58 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7A96021F9DE7 for ; Sun, 23 Jun 2013 20:16:58 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56399975; Sun, 23 Jun 2013 23:15:38 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 23 Jun 2013 23:16:54 -0400 From: "Wendt, Chris" To: Paul Kyzivat Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd/DYG9JHkYsaU+vynseyHv19w== Date: Mon, 24 Jun 2013 03:16:53 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> <51C7B7E6.5010100@alum.mit.edu> In-Reply-To: <51C7B7E6.5010100@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <982F2C4156F6374FBE0FD851EC933D74@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 03:17:03 -0000 In the context of STIR, I was referring mostly to the signing of the FROM a= ddress (caller), for example, ala RFC4474. But for domain routing, for R-URI, there would need to be some e164.arpa lo= okup to provide SIP URI with authoritative domain. But I think we got scol= ded for treading out-of-scope for discussing routing in this group already = :) On Jun 23, 2013, at 11:07 PM, Paul Kyzivat wrote: > On 6/23/13 10:26 PM, Wendt, Chris wrote: >>>=20 >>> In that hypothetical world, is there any significance to the domain nam= e in the URI? Are you in any way obligated to honor it when routing? >>>=20 >>=20 >> If I were to have my way, domain would be representation of the TN owner= s assertion. Signing of the SIP URI would prove that ownership and that's = what goes to the heart of what I believe we want to accomplish in this grou= p. >>=20 >> So, yes I believe domain has everything to do with verification and trac= ability of the caller-id (and yes the future of SIP peering and call routi= ng too) >=20 > I don't follow you. Consider a UA that is sending a request. It is given = a phone number by the caller. A priori it doesn't know the domain name that= owns the phone number. Yet it needs to form some sort of request in order = to send the request. So what domain name does it use? >=20 > Then when the request is routed, is the request routed based on the domai= n name, or the number? >=20 > For example, the originating UA may insert some domain, then route to its= outbound proxy, independent of either domain or number. That UA may have m= ade the domain correspond to the domain of its provider, or not. >=20 > When the request reaches the outbound proxy, belonging to the caller's pr= ovider, if the domain of the r-uri is that of the provider, then of course = it makes sense for the proxy to route the request further based on the numb= er. >=20 > But if the r-uri does *not* contain the domain of the provider, what shal= l the proxy do? Should it honor the uri, and route based on domain? Or may = it simply ignore the domain, translate the the r-uri based on the number an= d route it on based on that? >=20 > IMO, in the latter case it is obligated to route based on the domain of t= he r-uri. >=20 > Thanks, > Paul >=20 From hadriel.kaplan@oracle.com Sun Jun 23 22: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 24B9821E80B1 for ; Sun, 23 Jun 2013 22:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 e6mf3ljV9hEq for ; Sun, 23 Jun 2013 22:01:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B021E804B for ; Sun, 23 Jun 2013 22:01:04 -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 r5O50weu019511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jun 2013 05:00:59 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 r5O50s5h023715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 05:00:56 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5O50sWw026447; Mon, 24 Jun 2013 05:00:54 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-168-116.vpn.oracle.com (/10.154.168.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Jun 2013 22:00: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: <1E0475FDD84F0C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.com> Date: Mon, 24 Jun 2013 01:00:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> <51C7B7E6.5010100@alum.mit.edu> <1E0475FDD84F0! C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.com> To: "Wendt, Chris" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "" , Paul Kyzivat , Brian Rosen Subject: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 05:01:10 -0000 On Jun 23, 2013, at 11:16 PM, "Wendt, Chris" = wrote: > In the context of STIR, I was referring mostly to the signing of the = FROM address (caller), for example, ala RFC4474. >=20 [sorry for the length of this response; and this isn't about the above = statement but rather just sharing viewpoints based on the general topic] Yeah, I used to hold that view as well - that if the originating domains = signed using their =46rom domain name, then for domain names of = big/well-known service providers like Comcast, we could just believe = whatever the TN was they were claiming it to be. I was thinking we = could eventually create a reputation system for handling the smaller = providers, such that the verifying systems in terminating domains would = have a provisioned list of "trustworthy" providers it would believe = caller-id's from and anything else would not be trusted. I even wrote up a draft for doing rfc4474 in a way that could cross = through SBCs/B2BUAs, that assumed that model: http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 But now I'm thinking it wouldn't have worked for long, or not well = enough. One problem is a reputation model is messy: it's prone to error, and = hard to defend in court. These 'pink' carriers that are letting the bad = calls in would eventually have their domain name put on the naughty list = as we intended, but then what? You'd have to start blocking/redirecting = *all* their calls or even just clearing *all* their caller-ids, instead = of just their invalid ones. So there'll probably be either law suits or = complaints to the FCC. They'll claim it was a few isolated = incidents/errors or whatever, that you're either preventing competition = or impacting a public utility, and demand to be put back on the good = list. The 'pink' carriers aren't necessarily shady fly-by-night = operations - they could just be either under-managed or unaware. They = could be things like rural LECs or OTT providers, for example. Another problem is it's really hard to determine thresholds for being = bad. We can't put providers on the naughty list just due to a few bad = calls now and then - after all, mistakes are going to happen even for = the biggest providers. How many bad calls would it take to get on the = naughty list? Is it a different number per originator, because each = originator is of a different size and generates a different volume of = calls? Is it a percentage of calls? If you stay below the percentage, = how do we stop you from doing so forever, and having bad caller-ids = forever? Another problem is if we want this to ever be usable for international = calls, a reputation system gets super-messy. There're thousands of = providers in the world, and dealing with reputations for each of them is = very hard. Perhaps the big operators could handle it, but the smaller = ones (e.g., rural LECs) wouldn't be able to. You could try sharing = reputation lists - but it'd be full of errors for the reasons I = mentioned earlier. Even for the large providers it would be a massive = operational headache. So now I'm thinking the only way to handle this thing is to know whether = the originating domain truly has the right to claim a given caller-id = number or not for a given call. It needs to be something that's as = automated as possible, to reduce operational burden. And at the same = time it has to avoid claims of prejudice if caller-ids are deemed = invalid, by detecting which specific calls are illegitimate, having a = low false-positive rate, and based on some common ultimate authority for = the numbers. It sucks because it's going to be really painful to do this stuff, = whatever we end up doing; but no one's come up with an easier way so = far. :( -hadriel From sm@resistor.net Mon Jun 24 00:03: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 2639C11E80DC for ; Mon, 24 Jun 2013 00:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 kgWEkUXT22Et for ; Mon, 24 Jun 2013 00:03:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6726E21F9ABE for ; Mon, 24 Jun 2013 00:03:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5O73bIs028566 for ; Mon, 24 Jun 2013 00:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372057421; bh=WTh2MOi9Y+krlr+PxJKVkCHR2fSJSEGaOz5agCLakrg=; h=Date:To:From:Subject:In-Reply-To:References; b=oCjfo3QxFGPC1tcLKRvgQB3NHOWXN9KrDHVzBzVaAT0UHSLZKBJ+XfTltXRu8Gbsm Kt+J0drVYq2wT/j1oYQA3hjYqLONi3hYR9jUhBSL+5Fe/BraXFufGr2pXQ0Rxu0qvn HcOrauanwuGZLRovwV38nRcavvfQUIZ4ySAYSHAM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1372057421; i=@resistor.net; bh=WTh2MOi9Y+krlr+PxJKVkCHR2fSJSEGaOz5agCLakrg=; h=Date:To:From:Subject:In-Reply-To:References; b=kAo4FXtESgOgK3RP4K0/DOXBvj8upUIO4/W1tRyqo+OroQ+D59awUoHP519yAfTlu ub0gcbD5Zs95LjWacKS2/TcedkAErpuKX0PemTD2Z8Q1nY7FVkgxxX/bVawbo8mEdj b0upqcm7DpW+qCbV8KbRbAWPUlBVubB7Nc8dUkyo= Message-Id: <6.2.5.6.2.20130623233213.0b594438@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 23 Jun 2013 23:43:07 -0700 To: stir@ietf.org From: SM In-Reply-To: References: <2B0F677F0B95454297753F58D4A07FA30127CE8A38@FHDP1LUMXC7V31.us.one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 07:03:43 -0000 At 10:42 19-06-2013, Peterson, Jon wrote: >Henning has some charts about the bad behind swatting, vishing and What do these people have in common? Justin Bieber Russell Brand P. Diddy Ashton Kutcher Miley Cyrus Kanye West Justin Timberlake Selena Gomez Rhianna Each of those cost LAPD USD 10,000/-. Regards, -sm From chris_wendt@cable.comcast.com Mon Jun 24 04:25: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 16E1911E8104 for ; Mon, 24 Jun 2013 04:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.239 X-Spam-Level: X-Spam-Status: No, score=-4.239 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 44viq6se+cPi for ; Mon, 24 Jun 2013 04:25:23 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9AA11E8129 for ; Mon, 24 Jun 2013 04:25:23 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78906107; Mon, 24 Jun 2013 05:24:26 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Mon, 24 Jun 2013 07:25:16 -0400 From: "Wendt, Chris" To: Hadriel Kaplan Thread-Topic: Domain signing vs. TN authorities (was: RE: URI formats...) Thread-Index: AQHOcM2AE7WnUNsGNU2yNfJPirRrXg== Date: Mon, 24 Jun 2013 11:25:15 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD941930C1E@PACDCEXMB01.cable.comcast.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> <51C7B7E6.5010100@alum.mit.edu> <1E0475FDD84F0! C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Kyzivat , Brian Rosen Subject: Re: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 11:25:29 -0000 I can't totally disagree. The world where service providers turn on basica= lly spam filters and start blocking calls doesn't seem "right" and probably= will be a hard pill to swallow, whether it's voluntary or regulated or wha= tever. But I think at least you have traceability and at a minimum wholesale or tr= unking providers will have a clear signal to realize they are signing calle= r-id on behalf of their customers (or passing the responsibility to their c= ustomers) and therefore will be the first call from an "authority" whether = regulatory or criminal or civil when bad things start happening. This, in = my opinion, will keep the system more honest, and maybe is the best state w= e can hope for in the end. -Chris On Jun 24, 2013, at 1:00 AM, Hadriel Kaplan wro= te: >=20 > On Jun 23, 2013, at 11:16 PM, "Wendt, Chris" wrote: >=20 >> In the context of STIR, I was referring mostly to the signing of the FRO= M address (caller), for example, ala RFC4474. >>=20 >=20 > [sorry for the length of this response; and this isn't about the above st= atement but rather just sharing viewpoints based on the general topic] >=20 > Yeah, I used to hold that view as well - that if the originating domains = signed using their From domain name, then for domain names of big/well-know= n service providers like Comcast, we could just believe whatever the TN was= they were claiming it to be. I was thinking we could eventually create a = reputation system for handling the smaller providers, such that the verifyi= ng systems in terminating domains would have a provisioned list of "trustwo= rthy" providers it would believe caller-id's from and anything else would n= ot be trusted. >=20 > I even wrote up a draft for doing rfc4474 in a way that could cross throu= gh SBCs/B2BUAs, that assumed that model: > http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01 >=20 > But now I'm thinking it wouldn't have worked for long, or not well enough= . >=20 > One problem is a reputation model is messy: it's prone to error, and hard= to defend in court. These 'pink' carriers that are letting the bad calls = in would eventually have their domain name put on the naughty list as we in= tended, but then what? You'd have to start blocking/redirecting *all* thei= r calls or even just clearing *all* their caller-ids, instead of just their= invalid ones. So there'll probably be either law suits or complaints to t= he FCC. They'll claim it was a few isolated incidents/errors or whatever, = that you're either preventing competition or impacting a public utility, an= d demand to be put back on the good list. The 'pink' carriers aren't neces= sarily shady fly-by-night operations - they could just be either under-mana= ged or unaware. They could be things like rural LECs or OTT providers, for= example. >=20 > Another problem is it's really hard to determine thresholds for being bad= . We can't put providers on the naughty list just due to a few bad calls n= ow and then - after all, mistakes are going to happen even for the biggest = providers. How many bad calls would it take to get on the naughty list? I= s it a different number per originator, because each originator is of a dif= ferent size and generates a different volume of calls? Is it a percentage = of calls? If you stay below the percentage, how do we stop you from doing = so forever, and having bad caller-ids forever? >=20 > Another problem is if we want this to ever be usable for international ca= lls, a reputation system gets super-messy. There're thousands of providers= in the world, and dealing with reputations for each of them is very hard. = Perhaps the big operators could handle it, but the smaller ones (e.g., rur= al LECs) wouldn't be able to. You could try sharing reputation lists - but= it'd be full of errors for the reasons I mentioned earlier. Even for the = large providers it would be a massive operational headache. >=20 > So now I'm thinking the only way to handle this thing is to know whether = the originating domain truly has the right to claim a given caller-id numbe= r or not for a given call. It needs to be something that's as automated as= possible, to reduce operational burden. And at the same time it has to av= oid claims of prejudice if caller-ids are deemed invalid, by detecting whic= h specific calls are illegitimate, having a low false-positive rate, and ba= sed on some common ultimate authority for the numbers. >=20 > It sucks because it's going to be really painful to do this stuff, whatev= er we end up doing; but no one's come up with an easier way so far. > :( >=20 > -hadriel >=20 From pkyzivat@alum.mit.edu Mon Jun 24 08:10: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 380CF21E8115 for ; Mon, 24 Jun 2013 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgEFljh3fzWb for ; Mon, 24 Jun 2013 08:10:40 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C9D2C21F9CF5 for ; Mon, 24 Jun 2013 08:10:39 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id sBio1l0021ap0As58FAfJ0; Mon, 24 Jun 2013 15:10:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id sFAe1l0143ZTu2S3iFAegG; Mon, 24 Jun 2013 15:10:39 +0000 Message-ID: <51C8616D.3070901@alum.mit.edu> Date: Mon, 24 Jun 2013 11:10:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> <51C4BBD4.5030208@alum.mit.edu> <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com> In-Reply-To: <4535B4B3-7149-4D5F-8838-A6B3563ED795@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=1372086639; bh=8fUO45T8RCOYQQKEZxqAtrNmJOAvZCNopNp+S1EBD88=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V3f1qNnv1dMjiDgjBzjbFHIR4IhcAOT+S8Hu+D9OJKf7VfSKkEkBDqriW5Rc8eeXa bsohX8cibdj+/wo3KWKN1Z86x2YLsx0nyZgzcXiUonThc0yyI/bgl7CMNb4MkCku1e SkOBGePzGkSo8bEo37AK5d7x+AxaMsOoz4U/aQfEdvkVCJ3g+gfKOhNvxqmHekBEi0 UleK+efb7NP+AcPyaSOPJhErar2buQ+jeEeH+AXtosiC5kNehRA4p391mDaohuecoJ u/bEkxXPgWPyws2PiWFkZHKvd0xIcP8rz183LtJZulBZTbUvsbq6uvnCPcMkCEpLJ8 CUR+tmKNpz31w== Cc: stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 15:10:47 -0000 On 6/22/13 3:44 PM, Hadriel Kaplan wrote: > > On Jun 21, 2013, at 4:47 PM, Paul Kyzivat wrote: > >> On 6/20/13 3:46 PM, Hadriel Kaplan wrote: >> >>> And there's no "new" money for this - this stuff doesn't create a new revenue-generating feature, nor a feature one can use for competitive advantage. This thing is just a cost sink: another red line item for opex and capex, with no black line to offset it. It's got to be as cheap as possible. And it's got to be something we think will actually *work*. We can be wrong in the end of course, but we can't believe we'll be wrong from the start! >> >> What about the $5/month fee for "block spam calls"? :-) > > > I can't tell if you were being serious or not, so I'll reply in case you are. :) It was only half tongue in cheek. My point was that if this is something that costs the providers something they will probably do their best to monetize it one way or another. Maybe they'll just call it a "fee" with a name that makes it sound like a government regulation, even if it isn't, and certainly if it is. Thanks, Paul > Having a validated Caller-ID doesn't block spam calls. It just reduces them, by removing the ones with spoofed caller-ids. Just like I get tons of email spam from perfectly legitimate email addresses. Would you pay $5/month for something that didn't actually block the spam calls? We're already supposed to get do-not-call listing for free, and arguably beyond that it's hard to determine what is really spam vs. legitimate bulk-calling. > > Would you pay $5/month for "no spoofed caller-ids" - i.e., just for legitimate caller-ids? My guess is most every-day users expect they're already getting that, and that it's part of the service. > > But having said that, it's definitely possible that certain corporations or organizations would pay for "verified" caller-ids. So there probably will be some new revenue for some carriers for a time. But for such a thing to work, it would require most numbers to be verifiable, which means most carriers doing it, which means most calls will be verifiable for everyone anyway, which means ultimately it won't be worth much to get what everyone else gets for free as part of their phone service. > > -hadriel > > From pkyzivat@alum.mit.edu Mon Jun 24 08: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 1013321E80E9 for ; Mon, 24 Jun 2013 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=0.117, 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 oqshqUVshHN0 for ; Mon, 24 Jun 2013 08:30:46 -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 B4B0011E813A for ; Mon, 24 Jun 2013 08:30:46 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta10.westchester.pa.mail.comcast.net with comcast id sDVG1l0021GhbT85AFWmHi; Mon, 24 Jun 2013 15:30:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id sFWl1l01G3ZTu2S3TFWmRL; Mon, 24 Jun 2013 15:30:46 +0000 Message-ID: <51C86624.8010209@alum.mit.edu> Date: Mon, 24 Jun 2013 11:30:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.co m> In-Reply-To: <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@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=1372087846; bh=nCcD+5405KHHO1njF1hXyduMi+DrhrUrEnmXLK8CeE8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DY4SLIEWBbB6rAKtbWdHzDyro2IV7PEWsmFNkbFEYHHv1DlwOTCyhxBF4ErxCHI6n 09/ZvpEnH96Wtr5gtfoJS+6YaciAiUPojCkq7bb6vvRlj8JjQUH531KNb+kinO+8nv 0eXAY3VTkYq0U3xSYt5GVPzJmqCHSNw9w1vhqx7WmAHOafJ/W8tnsNu8MvJi7dkvos gJHsPooqiifrG7H0UVsZ1/85KCwgND07EUL9BJ+TvpoiGoJ2Rz/uJ2pmWyUK0WzA9H uxRaB9xTGsaVVsx92KX35b63pNFQ2B7eRM0kOcq4XM8nyUa4EpDtzOlCwYWtt4YjPN IzFAaFskZaLWQ== Cc: "Wendt, Chris" , "" , Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 15:30:54 -0000 On 6/22/13 4:30 PM, Hadriel Kaplan wrote: > > On Jun 22, 2013, at 9:25 AM, Paul Kyzivat wrote: > >> *Of course* the sending operator (signer) can look at the original message and figure out what the corresponding E.164 is for the caller, and probably for the callee too. And so can use those to sign the message. >> >> And presumably the verifier will be able to look at the received message and be able to figure out the E.164 number for the recipient, since it knows where it is going to be received. >> >> But it is far from clear that the verifier will be able to look at the received message and be able to figure out the E.164 number for the caller. It may just see a localized form of that number that is meaningful in the caller's context. And without being familiar with the caller's context that isn't enough. > > Ahhh - so what you're saying is that canonicalization will work for the To-number, but not the From-number. Sorry, missed that point in your original email. > > >> STIR *could* make an assumption (requirement?) that whatever value is used be rewritten along the path from signer to verifier so that the verifier will be able to do the verification. But if that is the intent, then it had better be stated with great clarity. > > Right, I think that is a basic assumption and we could even write it in as a requirement. And it's not as ludicrous as it sounds to do that. For one thing, afaict it's actually the case today. At least on SBCs, whenever I've seen rewriting of the To-URI, there's a corresponding rewrite of the From-URI. In practice, operators of SIP domains do use the From-URI for stuff, so they rewrite them as they exit/enter domains. > > But even if it *weren't* the case, that instead a terminating domain receives a From-URI in a format it can't determine an E.164 for, then it shouldn't be displaying it as a caller-id on its subscribers' phones. Well, there is "shouldn't", and there is "SHOULD NOT", and there is "do" or "don't". People want to see the caller id. So a provider has incentive to provide what it has. I think I used to see this issue on Cisco phones for calls between Cisco locations. (Of course these probably never left the Cisco domain, so one might argue that the same rules don't apply.) There were dialing rules that allowed short dial strings of various forms for dialing within a facility and between facilities, along with longer dial strings for dialing numbers outside. And routinely the dial string was displayed to the callee as the caller id. I don't recall what showed to someone outside Cisco. Most likely that was more correct. It wouldn't have been a particular issue if the dialing rules were the same at every facility, but they weren't. > So if the verification fails or is un-doable due to receiving such an unknown string, then arguably it's achieving the correct result: the caller-id is unverified. Obviously at a high-level we don't *want* that to happen - we want to be able to successfully verify legitimate caller-ids, because otherwise from the user's perspective it's a false-positive - but over time those things will sort themselves out. *IF* there was a way to display what you have, yet indicate that it is unverified, then that would be an improvement. Right now we don't have that. It would then also provide the incentive for the caller to provide the caller id in a form that *can* be verified. > That's why I was wondering if we should put a copy of the E.164 numbers into the Identity header, to help the operators troubleshoot failures and sort them out. For the purpose of *stir*, putting the full E.164 numbers *somewhere*, early on, and carrying it all the way to the end, would be a solution. I would *like* to see the same for To/From/R-URI, etc. but that is a discussion for a different forum, and it is harder to achieve. Thanks, Paul >> But I continue to find this rediculous - to depend on constant rewriting throughout the path of the message rather than canonicalizing at the endpoints. It is the antithesis of the E2E principal. (But as a precedent, it is exactly analogous to what NATs do.) > > "Endpoints" have rarely ever been able to canonicalize. They have no knowledge of "contexts", or what is or is not a phone number, or what is or is not an E.164 number vs. national vs. local vs. short code vs. star code vs. just a string of digits. All they know is the user pressed digit buttons and a "call" or "send" button. So they just put those digits into a SIP To-URI and req-uri user portion. And they put the AoR they Registered into the From-URI, which again they don't know the semantics of but just use what they were configured to Register with. > > Arguably that's one of the reasons few people use 'user=phone' and Tel-URLs and such, and rewriting happens a lot. The RFCs assumed the endpoints were smart - that they'd somehow know the intentions of the human and the contexts of phone numbers, and put the right things in the To/From. And then we told the Proxies not to change those To/From's, because doing that was "evil" and subverted the endpoints' intentions. But in practice the endpoints are dumb and the 'proxies' are smart... at least for this topic anyway. ;) > > -hadriel > > > From philippe.fouquart@orange.com Mon Jun 24 09:11: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 F3B3621F9AE0 for ; Mon, 24 Jun 2013 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 eT1VmXaUQA9r for ; Mon, 24 Jun 2013 09:11:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BF2ED21F934C for ; Mon, 24 Jun 2013 09:11:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3AF51324CDA; Mon, 24 Jun 2013 18:11:42 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1CE3327C05B; Mon, 24 Jun 2013 18:11:42 +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; Mon, 24 Jun 2013 18:11:41 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMA== Date: Mon, 24 Jun 2013 16:11:41 +0000 Message-ID: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" 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.5.21.113319 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 16:11:57 -0000 > Just to be clear: I'm not suggesting anything change in the To/From/req-u= ri/etc.=20 > at all - they are whatever they are today, for you, in your network/syste= ms.=20=20=20 > If you ran wireshark, you'd see no difference. (well... other than there'= s=20 > a new "Identity" header or whatever) Thanks, I misunderstood what you wrote.=20 > Whether we have to get pre-agreement between the originator/signer and th= e=20 > terminator/verifier on this canonicalization is a critical subject -=20 > my *hope*, is that we can do it without needing any such agreement, becau= se=20 > having to do that would basically kill the entire idea. I agree both that it's a critical point and that such an agreement shouldn'= t be necessary, hopefully. I also do not quite see how a system where the v= erifier would rely on prior knowledge of what the signer's conventions were= would work - and scale.=20 Maybe I'm missing something but assuming that both work on the canonical fo= rm where the user-param are removed, the only realistic alternative I can t= hink of, given that this would in all likelihood be first implemented on a = per country basis, may be to provide an 'identity' represented as the dial = string in the national dialing plan or some variant of the kind, but a) I guess this would require a "context" if we want a reasonable chance to= see this adopted 'cross-border' and=20 b) if every country applies its own logic it will turn into yet another O&M= nightmare (see how we get confused with our respective trunk codes already= ... ;)=20 (unless we assume that this identity format may vary depending on the CdP p= arty, which I don't think is desirable either.)=20 I understand it may not be the priority here but as a target I think that g= rand plan could remain in scope, and again, I think the extra flexibility f= or a signer is quite minimal in most dialing plans and the added complexity= for the receiver is in my view not worth it.=20 Finally the irony of not providing a full canonical form is that an increas= ing number of user data profiles contains the subscriber number in its full= E.164 format, so it may actually require *extra work* to provide a differe= nt format in a CgP-related header. (I'm not referring to R-Us which in the = world I live in generally have to be manipulated as some point to see the l= ight of the CdP party's endpoint or they'll just never get there - if this = group were to address such use cases, the logic may have to be different IM= HO)=20=20 > I'm half-way done with a draft proposing a new Identity header thing, tha= t includes=20 > how the canonicalization works (or not). I hope to get the draft submitt= ed soon.=20=20 Looking forward to that... > Hah! Ya know, I was actually considering looking online to see if the tru= nk=20 > prefix was part of the number or not before I sent the email, because eve= ry=20 > time I call Europe I get confused about whether to dial the '0' or not, a= nd=20 > I *always* choose incorrectly. So this time I thought to myself: "every = time=20 > you chose before you get it wrong, and the obvious thing is the zero is n= ot=20 > included, so the obvious thing must be wrong because you got it wrong eve= ry=20 > other time before, so clearly the zero *is* included." And apparently I = think=20 > that way every time. :( :D... but I shouldn't smile: I apply the exact same logic to password varia= tions *all the time*... with similar success but more embarrassing conseque= nces :)=20 Seriously though, the only case of this kind nearby here is I think the mob= ile range in Italy where 0 is both the first digit of the dialing plan and = of the mobile NDC/SN, the others (that also use 0 I mean) actually follow E= .164 recommendation to use it (only) as a trunk prefix. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Friday, June 21, 2013 7:53 PM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 21, 2013, at 6:04 AM, philippe.fouquart@orange.com wrote: > I do understand that if originating party/signer and terminating party/ve= rifier both agree on a common implicit "context" for the digit string ("the= user part I'll be sending is a number, no need for a user=3Dphone or a '+'= , and I'll provide only the E.164 NDC-SN not the CC because my server can't= do it and you can figure out it comes from country CC because I'll send it= on trunk Y..."). I agree you don't need any particular syntactical element= s to flag that it's a phone number and determine its canonical form and I k= now we sometimes have to do it for operational reasons.=20=20 >=20 > I would argue, however, that outside a limited remit (eg in-net or nation= al calls, technical limitations of your vis-=E0-vis...), such practice does= n't scale well if the syntax you use is all over the place. It will general= ly become an O&M nightmare if you have as many agreements of that sort as y= ou have interconnect bilaterals and that's why we try and stick to the iden= tity formats defined in national or international SIP "profiles". 3966 migh= t not be perfect in some respects but I think the principle of providing a = canonical form whenever applicable or a context otherwise is well-grounded.= It sometimes require very little effort for the originating party to provi= de a 'reasonably-canonical' form for what it sends and a lot more effort fo= r the terminating party to manage a plethora of syntax variations and doubl= e-guess what the other guy meant (especially if you have three or four othe= r guys in between...).=20 Just to be clear: I'm not suggesting anything change in the To/From/req-uri= /etc. at all - they are whatever they are today, for you, in your network/s= ystems. If you ran wireshark, you'd see no difference. (well... other than= there's a new "Identity" header or whatever) Whether we have to get pre-agreement between the originator/signer and the = terminator/verifier on this canonicalization is a critical subject - my *ho= pe*, is that we can do it without needing any such agreement, because havin= g to do that would basically kill the entire idea. I'm half-way done with a draft proposing a new Identity header thing, that = includes how the canonicalization works (or not). I hope to get the draft = submitted soon. I was writing up a bigger draft on a way to replace all of= 4474, using the DNS approach for holding certs, mostly to see if DNS would= make sense for it or not, but that draft will take longer so I split out j= ust the parts about a new header and signature. > For the record, my phone may indeed display '330145295813' if "STIR treat= s it as an email-style name" but would definitely *reject* it "as an E.164"= because it knows 0 is only the E.164 trunk prefix in the French dialing pl= an :) (don't hate me for this, it was hard to resist) Hah! Ya know, I was actually considering looking online to see if the trunk= prefix was part of the number or not before I sent the email, because ever= y time I call Europe I get confused about whether to dial the '0' or not, a= nd I *always* choose incorrectly. So this time I thought to myself: "every= time you chose before you get it wrong, and the obvious thing is the zero = is not included, so the obvious thing must be wrong because you got it wron= g every other time before, so clearly the zero *is* included." And apparen= tly I think that way every time. :( -hadriel ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jon.peterson@neustar.biz Mon Jun 24 09:52: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 6D45511E8169 for ; Mon, 24 Jun 2013 09:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 MMpPZukEdDUe for ; Mon, 24 Jun 2013 09:52:33 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3103721F999C for ; Mon, 24 Jun 2013 09:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372093240; x=1687445601; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=kY4lHvNQCx IICLsFanRdKntZe4ysTf3vrkQSQl+1hts=; b=DI27ygVHbBFaxjJURNs9zIZEQY q6FkZ89UXP2A+p9UggNwcc0xikGhRFTVto/IwRMMIe6i9m/w4D/uXdZulv/A== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26785126; Mon, 24 Jun 2013 13:00:39 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 12:52:16 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuAA= Date: Mon, 24 Jun 2013 16:52:16 +0000 Message-ID: In-Reply-To: <51C4CE80.40701@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oOBAFU7N0Ez0uGJfBkbWzg== Content-Type: text/plain; charset="us-ascii" Content-ID: <6CC5DBE3D5E42C45A75614C9EC8A4A9F@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 16:52:37 -0000 I think a lot of it depends on how you understand "redundancy." How many security systems that provide identity for email are out there in some degree of use? There are technologies like PGP and S/MIME staged at the client or end-user level, there are techniques like DKIM up at the domain or intermediary level, and there are various places where mails are analyzed to prevent spam that surely remove some mail from impersonated identities. I'm sure we could add other technologies to that list. All of them are to various extents overlapping and complementary to one another, but all require a pretty different support infrastructure (some use PKI, some use DNS, some something else) and deployment footprint. No single thing solves the problem completely. I view the two prongs of the STIR proposal in a similar light. Jon Peterson Neustar, Inc. On 6/21/13 3:06 PM, "Dave Crocker" wrote: >On 6/20/2013 1:49 PM, Peterson, Jon wrote: >> Yes, I think there can be differences in how well two mechanisms like >>this >> perform, and I don't think it's ridiculous to propose that we should >>use a >> rely on one when possible, and the other when the first isn't possible. > > >This sort of belts-and-suspenders approach has obvious appeal, for the >reason you cite. It also is massively expensive; and it might introduce >some problematic interactions between the two. (The cliche "if you have >one watch you know what time it is; if you have two, you're never quite >sure" comes to mind.) > >Do you know of any examples of similar functional redundancy for >critical infrastructure services on the Internet? I can't think of one. > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From dhc@dcrocker.net Mon Jun 24 10:11: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 53DF121E811E for ; Mon, 24 Jun 2013 10:11:11 -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 cEydd+FKw6Kz for ; Mon, 24 Jun 2013 10:11:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC121E813C for ; Mon, 24 Jun 2013 10:10:44 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5OHAe62003752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 10:10:44 -0700 Message-ID: <51C87D8E.9080108@dcrocker.net> Date: Mon, 24 Jun 2013 10:10:38 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 24 Jun 2013 10:10:44 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 24 Jun 2013 17:11:11 -0000 Jon, On 6/24/2013 9:52 AM, Peterson, Jon wrote: > > I think a lot of it depends on how you understand "redundancy." How many You are confusing the word competitive with the word redundant. You are also confusing differences in functional intent with redundancy. PGP and S/MIME are directly competitive. They were established entirely independently, and not as backups to each other, as the current STIR proposal does for caller-id validation. DKIM performs an entirely different function from PGP or S/MIME. There's nothing 'redundant' about it with them. My question meant the word redundant according the the third definition listed in Miriam Webster: "serving as a duplicate for preventing failure of an entire system (as a spacecraft) upon failure of a single component" http://www.merriam-webster.com/dictionary/redundant > All of > them are to various extents overlapping and complementary to one another, OK. So you are also confusing complementary with redundant. SPF and DKIM are often classed as complementary. There is a core similarity in their goals. However they are entirely different mechanisms with substantially different semantics. So while they cna be said to have some overlap, their semantics do not come close to overlapping completely. Hence, their relationship is nothing like the redundancy being proposed for STIR. Redundant means that two things are essentially the same. Of the various examples you provided, only PGP and S/MIME are essentially the same. And, again, they are competitive, not proposed for parallel, long-term use. One /could/ sign a message with both, but I'm pretty sure I've never seen that done. So my original question stands: Where else has the IETF had an orchestrated design for functionally redundant mechanisms to be used always and simultaneously? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Mon Jun 24 10:18: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 1EA4221E8144 for ; Mon, 24 Jun 2013 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.366 X-Spam-Level: X-Spam-Status: No, score=-106.366 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 bou5DWP9nkcx for ; Mon, 24 Jun 2013 10:18:21 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 02B2F21E8119 for ; Mon, 24 Jun 2013 10:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372094468; x=1687448588; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=H/zLjBBMOx gNvEGfq22BTf+eSOnWd0yizOtybO3cN1w=; b=ZqNw0hLz/bId4FsEKVNzLh/ukb aFVKGgcmkKm+FD2HS92pvx5xLHZbI3FxZDwjBnZdDejcEX2YIbA5ZSUUEJfg== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25608283; Mon, 24 Jun 2013 13:21:07 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 13:18:02 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAHp9AP//jLWA Date: Mon, 24 Jun 2013 17:18:01 +0000 Message-ID: In-Reply-To: <51C87D8E.9080108@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LEYNKhLL2Un9Y23u2PtyXA== Content-Type: text/plain; charset="us-ascii" Content-ID: <666C73F56E50584E81AB00F3C2AB3A2C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 17:18:25 -0000 My point was that in so far as technologies like DKIM and technologies like S/MIME provide strategies for protecting against impersonation (among other things), their capabilities overlap. They do so by relying on quite different deployments and security infrastructures. The parallel to STIR is obvious. To your refined question, about using two approaches "always and simultaneously," some STIR deployments would be capable of doing both, and yes under the model I at least have in mind they would do both. Others will only be capable of doing one and will only do one. I mean, if my email client can do S/MIME and I possess appropriate credentials, and my domain has the proper infrastructure for DKIM, I would assume that my identity in mails coming from me would always, simultaneously be protected by both S/MIME and DKIM. Sure, it's kind of redundant, but not entirely redundant. The two STIR prongs have similar properties, I believe. Jon Peterson Neustar, Inc. On 6/24/13 10:10 AM, "Dave Crocker" wrote: >Jon, > > >On 6/24/2013 9:52 AM, Peterson, Jon wrote: >> >> I think a lot of it depends on how you understand "redundancy." How many > >You are confusing the word competitive with the word redundant. You are >also confusing differences in functional intent with redundancy. > >PGP and S/MIME are directly competitive. They were established entirely >independently, and not as backups to each other, as the current STIR >proposal does for caller-id validation. > >DKIM performs an entirely different function from PGP or S/MIME. >There's nothing 'redundant' about it with them. > >My question meant the word redundant according the the third definition >listed in Miriam Webster: > > "serving as a duplicate for preventing failure of an entire system > (as a spacecraft) upon failure of a single component" > > http://www.merriam-webster.com/dictionary/redundant > > >> All of >> them are to various extents overlapping and complementary to one >>another, > >OK. So you are also confusing complementary with redundant. > >SPF and DKIM are often classed as complementary. There is a core >similarity in their goals. However they are entirely different >mechanisms with substantially different semantics. So while they cna be >said to have some overlap, their semantics do not come close to >overlapping completely. Hence, their relationship is nothing like the >redundancy being proposed for STIR. > >Redundant means that two things are essentially the same. Of the >various examples you provided, only PGP and S/MIME are essentially the >same. And, again, they are competitive, not proposed for parallel, >long-term use. One /could/ sign a message with both, but I'm pretty >sure I've never seen that done. > > >So my original question stands: > > Where else has the IETF had an orchestrated design for >functionally redundant mechanisms to be used always and simultaneously? > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From fas_vm@surguttel.ru Mon Jun 24 10:29: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 833EF11E816E for ; Mon, 24 Jun 2013 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.266 X-Spam-Level: * X-Spam-Status: No, score=1.266 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 nuj0HHC+vPvz for ; Mon, 24 Jun 2013 10:29:36 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8936C11E816D for ; Mon, 24 Jun 2013 10:29:36 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 03BB8514A33; Mon, 24 Jun 2013 23:28:40 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.167]) by mail.s86.ru (Postfix) with ESMTPA id C7EC5513817 for ; Mon, 24 Jun 2013 23:28:36 +0600 (YEKT) Message-ID: <0AEF371E30CC43FB8A5E644053C28AFF@Gateway> From: "Anton Tveretin" To: Date: Mon, 24 Jun 2013 22:59:54 +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 130624-1, 24.06.2013), Outbound message X-Antivirus-Status: Clean Subject: [stir] "Doctor" problem X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 17:29:42 -0000 Hello All, Let me recall. A doctor makes a call from home, but she wants this call to appear as it is coming from her office. If she is able to connect to office's SP (proxy or B2BUA) and authenticate, there will be no problem at all. Just IP-based routing. But I think this is not the thing that is discussed. The credentials could be unavailable (esp. it is a SIM rather than password). But in this case, there will be just 2 identities (say doctor@home and doctor@office). The fact the person is the same does not matter. So we speak of something like a power of attorney granted by doctor@office to doctor@home. So consider the following: 1. Should this permission be dispathed from office SP to home SP immediately, or requsted on demand? Which methods (and protocols) to use? In the former case, something like e-mail or fax could be used (or leave this unspecified). In the latter case, real-time is unavoidable. 2. Should home SP route this call through office SP or not? If yes, how? Are there reasons for charging? 3. Should P-A-I be doctor@home or doctor@office? If former, would any entity consider this call spoofed? Regards, Anton From dhc@dcrocker.net Mon Jun 24 10:30: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 00FB721E8106 for ; Mon, 24 Jun 2013 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 dQAmN1wIykIe for ; Mon, 24 Jun 2013 10:30:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7A411E816F for ; Mon, 24 Jun 2013 10:30:21 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5OHUH0q004203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 10:30:20 -0700 Message-ID: <51C88227.5000705@dcrocker.net> Date: Mon, 24 Jun 2013 10:30:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 24 Jun 2013 10:30:20 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 24 Jun 2013 17:30:26 -0000 On 6/24/2013 10:18 AM, Peterson, Jon wrote: > > My point was that in so far as technologies like DKIM and technologies > like S/MIME provide strategies for protecting against impersonation (among > other things), their capabilities overlap. They do so by relying on quite > different deployments and security infrastructures. The parallel to STIR > is obvious. From a sufficiently high altitude, everything looks the same. Tree, mountain, car, whatever. I meant my question to be substantive. Not so abstract as to lose all utility. > To your refined question, about using two approaches "always and > simultaneously," some STIR deployments would be capable of doing both, I've queried once or twice explicitly about the redundancy and you've confirmed it. This is the first time you've said "some". That introduces a degree of uncertainty which automatically calls to question the utility. If it's done sometimes and not others, what is the benefit? Viable Internet protocols are not usually used that whimsical. > and > yes under the model I at least have in mind they would do both. Others > will only be capable of doing one and will only do one. I mean, if my > email client can do S/MIME and I possess appropriate credentials, and my > domain has the proper infrastructure for DKIM, I would assume that my > identity in mails coming from me would always, simultaneously be protected > by both S/MIME and DKIM. Jon, again, they are completely different semantics. They are used in completely different ways and by different actors. They are not redundant. > Sure, it's kind of redundant, No it's not. Really, in spite of Alice being a common referent in security discussions, we are not in Wonderland and the meaning of terms isn't that fluid. "Kind of" redundant doesn't compute. An ascii 'a' apears in many different words in this email. That does not make the words "redundant". The fact that there are some components of DKIM and S/MIME that are similar does not make them redundant. but not entirely > redundant. The two STIR prongs have similar properties, I believe. 1. They have exactly the same semantics. 2. They are proposed for simultaneous use by all callers. /That/ is redundancy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Mon Jun 24 10:59: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 CCC5F21E8133 for ; Mon, 24 Jun 2013 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FB_YOUR_REFI=0.333, 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 X9K+QAoOmYK8 for ; Mon, 24 Jun 2013 10:59:35 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6721E812C for ; Mon, 24 Jun 2013 10:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372096668; x=1687387403; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=r9r7RRoxXG dPM1N9NPguJoED9ZrDiiZSJA5OD9YgSRM=; b=dwIk0c0DroqiF7TkJUu5eN8bw2 ZsFnmbfI14vNbh2vzk+AsjOOqZvwEMyV9M2NosSjSTo7aR7wMvDJgVeTjW1g== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19922693; Mon, 24 Jun 2013 13:57:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 13:59:22 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAHp9AP//jLWAgAB4xoD//5LIAA== Date: Mon, 24 Jun 2013 17:59:22 +0000 Message-ID: In-Reply-To: <51C88227.5000705@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Aw704rUK8I3XecfRn8VGHQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <121BE2943F9B414482D13364E35A0A34@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 17:59:40 -0000 It's pretty clear to me that both S/MIME and DKIM provide protection against impersonation. As for the two prongs of STIR and their differing applicabilities, several times on the list, and in the drafts, we've noted that there are cases where telephone calls don't use SIP at all, but it would still be useful to prevent impersonation. If this hasn't been sufficient to explain why only "some" cases would use both prongs of STIR, I don't think the problem has been lack of clarity on our part. This has nothing to do with whimsy. Similarly, I am surprised that it is unclear that the actors that would use the two prongs of STIR are potentially different. Authentication and verification services can be instantiated by intermediaries. The out-of-band proposal is more likely to be staged at smart devices. The parallels to comparable actors, and mechanisms, in the email space are not merely the result of altitude sickness. If those points remain murky, it probably wouldn't be helpful to articulate the differences in scope or semantics of the proposed mechanisms. Since they are only proposals, and their scopes may shift if these become work items of the IETF, it's hard to speak to their eventual shape. Suffice it to say that at least for the input documents I was involved with, the in-band mechanism has more integrity protection in its scope, for example. That alone illustrates that they don't have exactly the same semantics. Certainly there is considerable overlap, enough that in fact I think handling these two work items in the scope of the same IETF group would be very useful, in part to make sure that they reuse as much as possible. Jon Peterson Neustar, Inc. On 6/24/13 10:30 AM, "Dave Crocker" wrote: >On 6/24/2013 10:18 AM, Peterson, Jon wrote: >> >> My point was that in so far as technologies like DKIM and technologies >> like S/MIME provide strategies for protecting against impersonation >>(among >> other things), their capabilities overlap. They do so by relying on >>quite >> different deployments and security infrastructures. The parallel to STIR >> is obvious. > > From a sufficiently high altitude, everything looks the same. Tree, >mountain, car, whatever. > >I meant my question to be substantive. Not so abstract as to lose all >utility. > > >> To your refined question, about using two approaches "always and >> simultaneously," some STIR deployments would be capable of doing both, > >I've queried once or twice explicitly about the redundancy and you've >confirmed it. This is the first time you've said "some". > >That introduces a degree of uncertainty which automatically calls to >question the utility. If it's done sometimes and not others, what is >the benefit? > >Viable Internet protocols are not usually used that whimsical. > > >> and >> yes under the model I at least have in mind they would do both. Others >> will only be capable of doing one and will only do one. I mean, if my >> email client can do S/MIME and I possess appropriate credentials, and my >> domain has the proper infrastructure for DKIM, I would assume that my >> identity in mails coming from me would always, simultaneously be >>protected >> by both S/MIME and DKIM. > >Jon, again, they are completely different semantics. They are used in >completely different ways and by different actors. They are not >redundant. > > >> Sure, it's kind of redundant, > >No it's not. > >Really, in spite of Alice being a common referent in security >discussions, we are not in Wonderland and the meaning of terms isn't >that fluid. "Kind of" redundant doesn't compute. > >An ascii 'a' apears in many different words in this email. That does >not make the words "redundant". The fact that there are some components >of DKIM and S/MIME that are similar does not make them redundant. > > > but not entirely >> redundant. The two STIR prongs have similar properties, I believe. > >1. They have exactly the same semantics. > >2. They are proposed for simultaneous use by all callers. > >/That/ is redundancy. > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From br@brianrosen.net Mon Jun 24 11:04: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 D06CF21E8133 for ; Mon, 24 Jun 2013 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.257 X-Spam-Level: X-Spam-Status: No, score=-100.257 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 pA+xj3eVOzl4 for ; Mon, 24 Jun 2013 11:04:13 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 594BC21F9DF6 for ; Mon, 24 Jun 2013 11:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=s3HFP9z7vi+mXTRLoE005IiTPjE+NUW61i8EDkFo0Vs=; b=ATFxbaSOdK6+xUY1/Zmd4opxNYsOlScRqUtK50kOdcesIox1G3LkNsztzO5bySrlySPnTeFlSe06VDihJuM4jj22ezbFJhVz71jQJbqs83f9KWjhQ5lBjMQItms5P49DP0C+Um1ACXgZ80F4+gRAJJk7xi5LgZ5ZPAzXvdrgWVI=; Received: from neustargw.va.neustar.com ([209.173.53.233]:41854 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrB7c-0003uD-Hh; Mon, 24 Jun 2013 14:04:12 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Brian Rosen X-Priority: 3 In-Reply-To: <0AEF371E30CC43FB8A5E644053C28AFF@Gateway> Date: Mon, 24 Jun 2013 14:04:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <685BBAD3-3192-43A8-A77A-7F5F79571E96@brianrosen.net> References: <0AEF371E30CC43FB8A5E644053C28AFF@Gateway> To: Anton Tveretin X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org Subject: Re: [stir] "Doctor" problem X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 18:04:17 -0000 What we have been discussing is inline below On Jun 24, 2013, at 12:59 PM, Anton Tveretin = wrote: > Hello All, > Let me recall. A doctor makes a call from home, but she wants this = call to appear as it is coming from her office. > If she is able to connect to office's SP (proxy or B2BUA) and = authenticate, there will be no problem at all. Just IP-based routing. > But I think this is not the thing that is discussed. The credentials = could be unavailable (esp. it is a SIM rather than password). But in = this case, there will be just 2 identities (say doctor@home and = doctor@office). The fact the person is the same does not matter. So we = speak of something like a power of attorney granted by doctor@office to = doctor@home. So consider the following: > 1. Should this permission be dispathed from office SP to home SP = immediately, or requsted on demand? Permission in advance > Which methods (and protocols) to use? Details to be decided, but generally, it's like another delegation - the = SP office delegates the right to use the TN to SP Home > In the former case, something like e-mail or fax could be used (or = leave this unspecified). In the latter case, real-time is unavoidable. I think we should have a protocol for the delegation, but it's not clear = that we absolutely need one > 2. Should home SP route this call through office SP or not? If yes, = how? Are there reasons for charging? No > 3. Should P-A-I be doctor@home or doctor@office? If former, would any = entity consider this call spoofed? Not clear we will specify. We're not standardizing the SIP protocol for = this operation, we're specifying the mechanism for assuring source = identity. Somewhat depends on the details of where the info for = asserting identity & signing comes from. > Regards, > Anton=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Mon Jun 24 11:24: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 A31BB11E8178 for ; Mon, 24 Jun 2013 11:24:52 -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 IeBTrxQvL6R2 for ; Mon, 24 Jun 2013 11:24:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6D11E8173 for ; Mon, 24 Jun 2013 11:24:48 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5OIOiI3005098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 11:24:47 -0700 Message-ID: <51C88EEA.2020505@dcrocker.net> Date: Mon, 24 Jun 2013 11:24:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 24 Jun 2013 11:24:47 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 24 Jun 2013 18:24:52 -0000 On 6/24/2013 10:59 AM, Peterson, Jon wrote: > > It's pretty clear to me that both S/MIME and DKIM provide protection > against impersonation. A semi-trailor and a ferrari both provide transportation. They are not redundant. If S/MIME and DKIM were redundant, there would be an operational basis for using one in place of the other. Since there isn't, they aren't. > As for the two prongs of STIR and their differing applicabilities, several > times on the list, and in the drafts, we've noted that there are cases > where telephone calls don't use SIP at all, but it would still be useful > to prevent impersonation. If this hasn't been sufficient to explain why > only "some" cases would use both prongs of STIR, I don't think the problem > has been lack of clarity on our part. This has nothing to do with whimsy. That explains the problem of concern. No one has challenged the statement of the problem. The issue is with the proposed solution, in terms of cost and likely utility. And lack of precedent for such a design proposal. > Similarly, I am surprised that it is unclear that the actors that would > use the two prongs of STIR are potentially different. You confirmed that both paths would be created by the same actor (the caller) for every call: http://www.ietf.org/mail-archive/web/stir/current/msg00423.html > Authentication and > verification services can be instantiated by intermediaries. The > out-of-band proposal is more likely to be staged at smart devices. The What do you mean "staged"? What do you mean smart devices? I don't recall their being cited in the proposal discussion so far. How is the type of device relevant? Simplistically, there are two functions at issue. One is creating the authorization information. The other is validating it. In the message I cite above, you confirm that creation of both kinds of authentication information would be by the same actor, the caller. Are you suggesting a different scenario now? While perhaps different actors in the sequence would do validation, that's separate from having wholly redundant creation for every call. > parallels to comparable actors, and mechanisms, in the email space are not > merely the result of altitude sickness. Which kind of sickness is responsible? > If those points remain murky, it probably wouldn't be helpful to > articulate the differences in scope or semantics of the proposed > mechanisms. Since they are only proposals, and their scopes may shift if > these become work items of the IETF, it's hard to speak to their eventual Jon, you appear to be saying that making a proposal carries no ability to respond to questions about it or to otherwise concrete. It sounds as if a proposal is to be adopted before it has serious substance or analysis. Since I doubt that you mean that, I don't understand your difficulty at responding to rather basic concerns. > shape. Suffice it to say that at least for the input documents I was > involved with, the in-band mechanism has more integrity protection in its > scope, for example. That alone illustrates that they don't have exactly > the same semantics. Unless I've misunderstood the purpose of this work, data integrity is an entirely secondary function (or even tertiary.) Let's not get distracted by differences that are secondary. The primary function is checking authorization of the telephone number in the From field. In this, the two mechanisms have exactly the same semantics, don't they? > Certainly there is considerable overlap, enough that in fact I think Having exactly the same primary function and producing exactly the same semantic result is not "overlap". It is redundancy. > handling these two work items in the scope of the same IETF group would be > very useful, in part to make sure that they reuse as much as possible. The issue isn't where to do the development work, but the benefit of pursuing entirely redundant mechanisms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Mon Jun 24 11:26: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 6A56E11E8178 for ; Mon, 24 Jun 2013 11:26:25 -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 XGJ26ALSEDq5 for ; Mon, 24 Jun 2013 11:26:21 -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 2C42011E8173 for ; Mon, 24 Jun 2013 11:26:21 -0700 (PDT) Message-ID: X-CheckPoint: {51C88F2C-10089-D2C987A5-1FFFF} From: Henning Schulzrinne To: "Peterson, Jon" , "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZQ== Date: Mon, 24 Jun 2013 18:25:47 +0000 References: <51C4CE80.40701@dcrocker.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 18:26:25 -0000 I'd add at least two "overlapping" solutions that may have parallels, namel= y SPF and various DNS-based blacklists. Slightly further afield, you have t= he newer anti-malware protocols, such as=0A= =0A= https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec=0A= =0A= Henning=0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Peterson, = Jon [jon.peterson@neustar.biz]=0A= Sent: Monday, June 24, 2013 12:52 PM=0A= To: dcrocker@bbiw.net=0A= Cc: stir@ietf.org; Brian Rosen=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= I think a lot of it depends on how you understand "redundancy." How many=0A= security systems that provide identity for email are out there in some=0A= degree of use? There are technologies like PGP and S/MIME staged at the=0A= client or end-user level, there are techniques like DKIM up at the domain= =0A= or intermediary level, and there are various places where mails are=0A= analyzed to prevent spam that surely remove some mail from impersonated=0A= identities. I'm sure we could add other technologies to that list. All of= =0A= them are to various extents overlapping and complementary to one another,= =0A= but all require a pretty different support infrastructure (some use PKI,=0A= some use DNS, some something else) and deployment footprint. No single=0A= thing solves the problem completely. I view the two prongs of the STIR=0A= proposal in a similar light.=0A= =0A= Jon Peterson=0A= Neustar, Inc.=0A= =0A= On 6/21/13 3:06 PM, "Dave Crocker" wrote:=0A= =0A= >On 6/20/2013 1:49 PM, Peterson, Jon wrote:=0A= >> Yes, I think there can be differences in how well two mechanisms like=0A= >>this=0A= >> perform, and I don't think it's ridiculous to propose that we should=0A= >>use a=0A= >> rely on one when possible, and the other when the first isn't possible.= =0A= >=0A= >=0A= >This sort of belts-and-suspenders approach has obvious appeal, for the=0A= >reason you cite. It also is massively expensive; and it might introduce= =0A= >some problematic interactions between the two. (The cliche "if you have= =0A= >one watch you know what time it is; if you have two, you're never quite=0A= >sure" comes to mind.)=0A= >=0A= >Do you know of any examples of similar functional redundancy for=0A= >critical infrastructure services on the Internet? I can't think of one.= =0A= >=0A= >d/=0A= >=0A= >--=0A= >Dave Crocker=0A= >Brandenburg InternetWorking=0A= >bbiw.net=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From dhc@dcrocker.net Mon Jun 24 11:35: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 829A521E815D for ; Mon, 24 Jun 2013 11:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 4asl-LdIUz9a for ; Mon, 24 Jun 2013 11:35:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA611E8175 for ; Mon, 24 Jun 2013 11:35:43 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5OIZaf8005266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 11:35:40 -0700 Message-ID: <51C89176.5000502@dcrocker.net> Date: Mon, 24 Jun 2013 11:35:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <51C4CE80.40701@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, 24 Jun 2013 11:35:40 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 24 Jun 2013 18:35:49 -0000 On 6/24/2013 11:25 AM, Henning Schulzrinne wrote: > I'd add at least two "overlapping" solutions that may have parallels, namely SPF and various DNS-based blacklists. Slightly further afield, you have the newer anti-malware protocols, such as Henning, Thanks for the followup. I'm trying to draw a distinction between two things having "some" relationship vs. being wholly redundant. SPF and blacklists have some relationship, but they are not at all redundant. SPF is an objective, mechanical technique for checking authorization of a sever to send mail that has a particular domain name in the SMTP MailFrom command. Success means the domain's use was authorized; failure means it wasn't. Success does /not/ mean that the message is from a good actor. SPF makes no assessment of actor quality. It turns out that failure doesn't guarantee that it's from a bad actor. (Thank you, mailing lists and other intermediaries, as well as configuration errors and user mobility.) Blacklists are highly subjective formulations of actor reputation. They offer a quality assessment. While there can be correlations between the two, they are wholly independent mechanisms with wholly different semantics (although some blacklists might use operational patterns involving SPF when formulating entries.) All of this is hugely different from having the caller exercising two semantically identical mechanisms for every call. /That/ is what I mean by redundant. Imagine that besides sending this email to the group, I sent the same message to everyone via IM. THAT would be redundant. Now imagine that each of us did that for every message we post to the group. THAT is equivalent to what is being proposed for STIR. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Mon Jun 24 12:08: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 7292021F9FC8 for ; Mon, 24 Jun 2013 12:08:24 -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 Db0JsgWmlUHw for ; Mon, 24 Jun 2013 12:08:20 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id D23C321F9F93 for ; Mon, 24 Jun 2013 12:08:19 -0700 (PDT) Message-ID: X-CheckPoint: {51C89922-1007A-D2C987A5-FFFF} From: Henning Schulzrinne To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17E= Date: Mon, 24 Jun 2013 19:08:18 +0000 References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> In-Reply-To: <51C89176.5000502@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 19:08:24 -0000 The overlap, if any, is largely between S/MIME, SPF and DKIM, all related t= o origin authentication. (Yes, I recognize that they validate different par= ts of the mail message, but that's probably as meaningful a distinction to = most users and sys admins as the difference between validating ANI and call= erID, which are the rough moral equivalents in the PSTN space.)=0A= =0A= That S/MIME also validates content is a good illustration - 4474 does the s= ame thing (possibly signing media-related items), which out-of-band wouldn'= t.=0A= =0A= The main difference between the two STIR modes discussed is between the act= ors involved and the likely deployment incentives. The in-band mechanism is= likely to be deployed by carriers, the out-of-band mechanism by end users,= such as legitimate call centers (and smart phones), for a variety of reaso= ns already discussed at length. I'm guessing that many of us are hopeful th= at we'll get much closer to 100% coverage with two mechanisms than with one= . The incremental validation effort is pretty minimal, and different entiti= es have different incentives to deploy one or the other, possibly on differ= ent timelines.=0A= =0A= For example, legitimate call centers and reverse-911 operations have incent= ives to deploy out-of-band mechanisms. They can't, in most cases, deploy in= -band solutions.=0A= =0A= Your main argument seems to be that this hasn't been done before. That argu= ment seems to carry only so far, even for email.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Dave Crocker [dhc@dcrocker.net]=0A= Sent: Monday, June 24, 2013 2:35 PM=0A= To: Henning Schulzrinne=0A= Cc: stir@ietf.org=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= On 6/24/2013 11:25 AM, Henning Schulzrinne wrote:=0A= > I'd add at least two "overlapping" solutions that may have parallels, nam= ely SPF and various DNS-based blacklists. Slightly further afield, you have= the newer anti-malware protocols, such as=0A= =0A= =0A= Henning,=0A= =0A= Thanks for the followup. I'm trying to draw a distinction between two=0A= things having "some" relationship vs. being wholly redundant. SPF and=0A= blacklists have some relationship, but they are not at all redundant.=0A= =0A= SPF is an objective, mechanical technique for checking authorization of=0A= a sever to send mail that has a particular domain name in the SMTP=0A= MailFrom command. Success means the domain's use was authorized;=0A= failure means it wasn't. Success does /not/ mean that the message is=0A= from a good actor. SPF makes no assessment of actor quality. It turns=0A= out that failure doesn't guarantee that it's from a bad actor. (Thank=0A= you, mailing lists and other intermediaries, as well as configuration=0A= errors and user mobility.)=0A= =0A= Blacklists are highly subjective formulations of actor reputation. They=0A= offer a quality assessment.=0A= =0A= While there can be correlations between the two, they are wholly=0A= independent mechanisms with wholly different semantics (although some=0A= blacklists might use operational patterns involving SPF when formulating=0A= entries.)=0A= =0A= All of this is hugely different from having the caller exercising two=0A= semantically identical mechanisms for every call. /That/ is what I mean=0A= by redundant.=0A= =0A= Imagine that besides sending this email to the group, I sent the same=0A= message to everyone via IM. THAT would be redundant. Now imagine that=0A= each of us did that for every message we post to the group. THAT is=0A= equivalent to what is being proposed for STIR.=0A= =0A= =0A= d/=0A= =0A= --=0A= Dave Crocker=0A= Brandenburg InternetWorking=0A= bbiw.net=0A= From Henning.Schulzrinne@fcc.gov Mon Jun 24 12:21: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 3EDA821F9A91 for ; Mon, 24 Jun 2013 12:21:55 -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 4aILlW-WJxk0 for ; Mon, 24 Jun 2013 12:21:51 -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 5408B21F84E3 for ; Mon, 24 Jun 2013 12:21:50 -0700 (PDT) Message-ID: X-CheckPoint: {51C89C4A-10031-D2C987A5-1FFFF} From: Henning Schulzrinne To: Paul Kyzivat , Hadriel Kaplan Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObdrfYLU7EUyIFUCNN4IneGpC0pk+43+AgABhigCAAaNWAIABgOgAgALYB4CAAADNCw== Date: Mon, 24 Jun 2013 19:21:45 +0000 References: <65BCFF30-AA46-42D1-80AD-41DE303E63E8@brianrosen.net> <8CD28031-2B7D-4D0A-B299-6D1780D341BC@oracle.com> <988AB632-7E4D-4D39-96C8-2179134F3A3D@oracle.com> <51C4BBD4.5030208@alum.mit.edu> <4535B4B3-7149-4D5F-8838-A6B3563ED795@oracle.com>, <51C8616D.3070901@alum.mit.edu> In-Reply-To: <51C8616D.3070901@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] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 19:21:55 -0000 Once you remove spoofing, there are two cases:=0A= =0A= (1) The entity is located in the US and violates the do-not-call list and T= CPA. They have now painted a fine-me target on their back. (Robocalls are s= trictly opt-in in the US for commercial use.) There is no do-not-email list= equivalent, so the analogy doesn't quite hold.=0A= =0A= (2) For entities that are on the borders of legitimacy, I suspect you'll se= e more crowd-sourced call blocking, as is already happening for smart phone= s. Right now, given the prevalence of spoofing, they are not very effective= in reducing the total volume of robocalls. (You could still get dubious en= tities rapidly switching between legitimate numbers, but that's an expensiv= e arms race, given that you'd probably have to get a new number every ten c= alls or so.)=0A= =0A= (3) The entity is located outside the US. How did they get the ability to o= riginate a signed call? If they had "help" by a carrier, that carrier has l= ost plausible deniability.=0A= =0A= I would also hope that this can be a competitive differentiator, particular= ly for new entrants. Gmail, to pick one example, seems to have picked up a = fair number of users based on the perception of its spam filtering mechanis= m.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu]=0A= Sent: Monday, June 24, 2013 11:10 AM=0A= To: Hadriel Kaplan=0A= Cc: stir@ietf.org=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= On 6/22/13 3:44 PM, Hadriel Kaplan wrote:=0A= >=0A= > On Jun 21, 2013, at 4:47 PM, Paul Kyzivat wrote:= =0A= >=0A= >> On 6/20/13 3:46 PM, Hadriel Kaplan wrote:=0A= >>=0A= >>> And there's no "new" money for this - this stuff doesn't create a new r= evenue-generating feature, nor a feature one can use for competitive advant= age. This thing is just a cost sink: another red line item for opex and ca= pex, with no black line to offset it. It's got to be as cheap as possible.= And it's got to be something we think will actually *work*. We can be wr= ong in the end of course, but we can't believe we'll be wrong from the star= t!=0A= >>=0A= >> What about the $5/month fee for "block spam calls"? :-)=0A= >=0A= >=0A= > I can't tell if you were being serious or not, so I'll reply in case you = are. :)=0A= =0A= It was only half tongue in cheek.=0A= =0A= My point was that if this is something that costs the providers=0A= something they will probably do their best to monetize it one way or=0A= another.=0A= =0A= Maybe they'll just call it a "fee" with a name that makes it sound like=0A= a government regulation, even if it isn't, and certainly if it is.=0A= =0A= Thanks,=0A= Paul=0A= =0A= > Having a validated Caller-ID doesn't block spam calls. It just reduces = them, by removing the ones with spoofed caller-ids. Just like I get tons o= f email spam from perfectly legitimate email addresses. Would you pay $5/m= onth for something that didn't actually block the spam calls? We're alread= y supposed to get do-not-call listing for free, and arguably beyond that it= 's hard to determine what is really spam vs. legitimate bulk-calling.=0A= >=0A= > Would you pay $5/month for "no spoofed caller-ids" - i.e., just for legit= imate caller-ids? My guess is most every-day users expect they're already = getting that, and that it's part of the service.=0A= >=0A= > But having said that, it's definitely possible that certain corporations = or organizations would pay for "verified" caller-ids. So there probably wi= ll be some new revenue for some carriers for a time. But for such a thing = to work, it would require most numbers to be verifiable, which means most c= arriers doing it, which means most calls will be verifiable for everyone an= yway, which means ultimately it won't be worth much to get what everyone el= se gets for free as part of their phone service.=0A= >=0A= > -hadriel=0A= >=0A= >=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From dhc@dcrocker.net Mon Jun 24 12: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 428FC21E8149 for ; Mon, 24 Jun 2013 12:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 WCjFJGO0K9uI for ; Mon, 24 Jun 2013 12:22:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A07D721E80FA for ; Mon, 24 Jun 2013 12:22:30 -0700 (PDT) Received: from [192.168.6.161] (ip-64-134-234-85.public.wayport.net [64.134.234.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5OJMOwo006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 12:22:28 -0700 Message-ID: <51C89C6E.1090603@dcrocker.net> Date: Mon, 24 Jun 2013 12:22:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@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, 24 Jun 2013 12:22:28 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 24 Jun 2013 19:22:48 -0000 Henning, On 6/24/2013 12:08 PM, Henning Schulzrinne wrote: > The main difference between the two STIR modes discussed is between > the actors involved and the likely deployment incentives. The in-band > mechanism is likely to be deployed by carriers, the out-of-band > mechanism by end users, such as legitimate call centers (and smart That's quite different from what Jon confirmed for me, namely that both would be done by the caller, every time. For an exercise of the type being done now, it's extremely important to be very clear about the usage scenarios that are being proposed. And so, just as an example, let's say the main model is a clean, end-to-end SIP-SIP, with an in-band authorization mechanism. but then let's say there is a need to handle SIP-SS7-SIP, where the SS7 "hop" might lose the authorization information. Then one can reasonably imagine a special mechanism to handle the hop, such as stashing the information in a side cache to be retrieved in the SS7>SIP transition. That's what I suggested a few days ago, but was instead told that the intent was to have the /caller/ do /both/ mechanisms /every time/. That is, both are being proposed as full, end-to-end mechanisms. At the least, it's important to get everyone sharing the same understanding of what is being proposed, in terms of its architecture and its usage. Otherwise, we really are in Wonderland. Where each person has whatever meaning they wish and no one can communicate. Pessimal interoperability. > phones), for a variety of reasons already discussed at length. I'm > guessing that many of us are hopeful that we'll get much closer to > 100% coverage with two mechanisms than with one. Unfortunately there is just as much chance -- and maybe more -- of getting /less/. Having two different mechanisms creates confusion about which to use, nevermind the added cost of everyone having to support both, which creates a disincentive to implement either. > The incremental > validation effort is pretty minimal, and different entities have > different incentives to deploy one or the other, possibly on > different timelines. I don't think I've seen reference to "incremental" validation and am not sure what you mean. Neither of the two mechanisms being proposed sound incremental to me. > For example, legitimate call centers and reverse-911 operations have > incentives to deploy out-of-band mechanisms. They can't, in most > cases, deploy in-band solutions. > > Your main argument seems to be that this hasn't been done before. > That argument seems to carry only so far, even for email. It's useful to know whether there is an experiential base for a paradigm. When it exists, it helps to evaluate costs, utilities and risks. That doesn't preclude innovation at the level of basic paradigms, of course, but it means that the risks are dramatically higher. Most new paradigms fail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Mon Jun 24 12:24: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 6EA4821E810C for ; Mon, 24 Jun 2013 12:24:13 -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_52=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 2LT3kp6USofr for ; Mon, 24 Jun 2013 12:24:05 -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 1621111E817F for ; Mon, 24 Jun 2013 12:23:57 -0700 (PDT) Message-ID: X-CheckPoint: {51C89CCD-10023-D2C987A5-FFFF} From: Henning Schulzrinne To: "Wendt, Chris" , Hadriel Kaplan Thread-Topic: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) Thread-Index: AQHOcM2VIngLz1T/FUeBFISsCddFAplFPrOH Date: Mon, 24 Jun 2013 19:23:56 +0000 References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> <51C7B7E6.5010100@alum.mit.edu> <1E0475FDD84F0! C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.com> , <1E0475FDD84F0C42A9F46570BB946FD941930C1E@PACDCEXMB01.cable.comcast.com> In-Reply-To: <1E0475FDD84F0C42A9F46570BB946FD941930C1E@PACDCEXMB01.cable.comcast.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: "" , Paul Kyzivat , Brian Rosen Subject: Re: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 19:24:16 -0000 You could imagine the equivalent of "block anonymous calls" service that's = user-invoked ("block unauthenticated calls"), or interfaces to third-party = services chosen by the user. They may, for example, enable that service if = their call center is under attack or robocalls are flaring up.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Wendt, Chr= is [Chris_Wendt@cable.comcast.com]=0A= Sent: Monday, June 24, 2013 7:25 AM=0A= To: Hadriel Kaplan=0A= Cc: ; Paul Kyzivat; Brian Rosen=0A= Subject: Re: [stir] Domain signing vs. TN authorities (was: RE: URI for= mats...)=0A= =0A= I can't totally disagree. The world where service providers turn on basica= lly spam filters and start blocking calls doesn't seem "right" and probably= will be a hard pill to swallow, whether it's voluntary or regulated or wha= tever.=0A= =0A= But I think at least you have traceability and at a minimum wholesale or tr= unking providers will have a clear signal to realize they are signing calle= r-id on behalf of their customers (or passing the responsibility to their c= ustomers) and therefore will be the first call from an "authority" whether = regulatory or criminal or civil when bad things start happening. This, in = my opinion, will keep the system more honest, and maybe is the best state w= e can hope for in the end.=0A= =0A= -Chris=0A= =0A= On Jun 24, 2013, at 1:00 AM, Hadriel Kaplan wro= te:=0A= =0A= >=0A= > On Jun 23, 2013, at 11:16 PM, "Wendt, Chris" wrote:=0A= >=0A= >> In the context of STIR, I was referring mostly to the signing of the FRO= M address (caller), for example, ala RFC4474.=0A= >>=0A= >=0A= > [sorry for the length of this response; and this isn't about the above st= atement but rather just sharing viewpoints based on the general topic]=0A= >=0A= > Yeah, I used to hold that view as well - that if the originating domains = signed using their From domain name, then for domain names of big/well-know= n service providers like Comcast, we could just believe whatever the TN was= they were claiming it to be. I was thinking we could eventually create a = reputation system for handling the smaller providers, such that the verifyi= ng systems in terminating domains would have a provisioned list of "trustwo= rthy" providers it would believe caller-id's from and anything else would n= ot be trusted.=0A= >=0A= > I even wrote up a draft for doing rfc4474 in a way that could cross throu= gh SBCs/B2BUAs, that assumed that model:=0A= > http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01=0A= >=0A= > But now I'm thinking it wouldn't have worked for long, or not well enough= .=0A= >=0A= > One problem is a reputation model is messy: it's prone to error, and hard= to defend in court. These 'pink' carriers that are letting the bad calls = in would eventually have their domain name put on the naughty list as we in= tended, but then what? You'd have to start blocking/redirecting *all* thei= r calls or even just clearing *all* their caller-ids, instead of just their= invalid ones. So there'll probably be either law suits or complaints to t= he FCC. They'll claim it was a few isolated incidents/errors or whatever, = that you're either preventing competition or impacting a public utility, an= d demand to be put back on the good list. The 'pink' carriers aren't neces= sarily shady fly-by-night operations - they could just be either under-mana= ged or unaware. They could be things like rural LECs or OTT providers, for= example.=0A= >=0A= > Another problem is it's really hard to determine thresholds for being bad= . We can't put providers on the naughty list just due to a few bad calls n= ow and then - after all, mistakes are going to happen even for the biggest = providers. How many bad calls would it take to get on the naughty list? I= s it a different number per originator, because each originator is of a dif= ferent size and generates a different volume of calls? Is it a percentage = of calls? If you stay below the percentage, how do we stop you from doing = so forever, and having bad caller-ids forever?=0A= >=0A= > Another problem is if we want this to ever be usable for international ca= lls, a reputation system gets super-messy. There're thousands of providers= in the world, and dealing with reputations for each of them is very hard. = Perhaps the big operators could handle it, but the smaller ones (e.g., rur= al LECs) wouldn't be able to. You could try sharing reputation lists - but= it'd be full of errors for the reasons I mentioned earlier. Even for the = large providers it would be a massive operational headache.=0A= >=0A= > So now I'm thinking the only way to handle this thing is to know whether = the originating domain truly has the right to claim a given caller-id numbe= r or not for a given call. It needs to be something that's as automated as= possible, to reduce operational burden. And at the same time it has to av= oid claims of prejudice if caller-ids are deemed invalid, by detecting whic= h specific calls are illegitimate, having a low false-positive rate, and ba= sed on some common ultimate authority for the numbers.=0A= >=0A= > It sucks because it's going to be really painful to do this stuff, whatev= er we end up doing; but no one's come up with an easier way so far.=0A= > :(=0A= >=0A= > -hadriel=0A= >=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Mon Jun 24 12:30: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 B2D3E21E816C for ; Mon, 24 Jun 2013 12:30:04 -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_52=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 EXx8PLjfXwIG for ; Mon, 24 Jun 2013 12:30:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 641D521E815A for ; Mon, 24 Jun 2013 12:29:59 -0700 (PDT) Message-ID: X-CheckPoint: {51C89E36-1008B-D2C987A5-2FFFF} From: Henning Schulzrinne To: Hadriel Kaplan , "Wendt, Chris" Thread-Topic: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) Thread-Index: AQHOcJfhrPJhHevVGUSkoy+FwbzzDplFQH/r Date: Mon, 24 Jun 2013 19:29:58 +0000 References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <1E0475FDD84F0C42A9F46570BB946FD941930669@PACDCEXMB01.cable.comcast.com> <51C7B7E6.5010100@alum.mit.edu> <1E0475FDD84F0! C42A9F46570BB946FD9419307C8@PACDCEXMB01.cable.comcast.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: "" , Paul Kyzivat , Brian Rosen Subject: Re: [stir] Domain signing vs. TN authorities (was: RE: URI formats...) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 19:30:04 -0000 To add one example: There are now a fair number of "hosted" telephony provi= ders (Twilio is a well-known one). Just like hosting providers in the web s= pace, I suspect you'd get the same problem Hadriel describes below for them= . There are legitimate concerns that suppressing bad actors could also conv= eniently suppress unwelcome competition. Thus, a "no excuses" solution does= seem called for.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hadriel Ka= plan [hadriel.kaplan@oracle.com]=0A= Sent: Monday, June 24, 2013 1:00 AM=0A= To: Wendt, Chris=0A= Cc: ; Paul Kyzivat; Brian Rosen=0A= Subject: [stir] Domain signing vs. TN authorities (was: RE: URI formats...)= =0A= =0A= On Jun 23, 2013, at 11:16 PM, "Wendt, Chris" wrote:=0A= =0A= > In the context of STIR, I was referring mostly to the signing of the FROM= address (caller), for example, ala RFC4474.=0A= >=0A= =0A= [sorry for the length of this response; and this isn't about the above stat= ement but rather just sharing viewpoints based on the general topic]=0A= =0A= Yeah, I used to hold that view as well - that if the originating domains si= gned using their From domain name, then for domain names of big/well-known = service providers like Comcast, we could just believe whatever the TN was t= hey were claiming it to be. I was thinking we could eventually create a re= putation system for handling the smaller providers, such that the verifying= systems in terminating domains would have a provisioned list of "trustwort= hy" providers it would believe caller-id's from and anything else would not= be trusted.=0A= =0A= I even wrote up a draft for doing rfc4474 in a way that could cross through= SBCs/B2BUAs, that assumed that model:=0A= http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01=0A= =0A= But now I'm thinking it wouldn't have worked for long, or not well enough.= =0A= =0A= One problem is a reputation model is messy: it's prone to error, and hard t= o defend in court. These 'pink' carriers that are letting the bad calls in= would eventually have their domain name put on the naughty list as we inte= nded, but then what? You'd have to start blocking/redirecting *all* their = calls or even just clearing *all* their caller-ids, instead of just their i= nvalid ones. So there'll probably be either law suits or complaints to the= FCC. They'll claim it was a few isolated incidents/errors or whatever, th= at you're either preventing competition or impacting a public utility, and = demand to be put back on the good list. The 'pink' carriers aren't necessa= rily shady fly-by-night operations - they could just be either under-manage= d or unaware. They could be things like rural LECs or OTT providers, for e= xample.=0A= =0A= Another problem is it's really hard to determine thresholds for being bad. = We can't put providers on the naughty list just due to a few bad calls now= and then - after all, mistakes are going to happen even for the biggest pr= oviders. How many bad calls would it take to get on the naughty list? Is = it a different number per originator, because each originator is of a diffe= rent size and generates a different volume of calls? Is it a percentage of= calls? If you stay below the percentage, how do we stop you from doing so= forever, and having bad caller-ids forever?=0A= =0A= Another problem is if we want this to ever be usable for international call= s, a reputation system gets super-messy. There're thousands of providers i= n the world, and dealing with reputations for each of them is very hard. P= erhaps the big operators could handle it, but the smaller ones (e.g., rural= LECs) wouldn't be able to. You could try sharing reputation lists - but i= t'd be full of errors for the reasons I mentioned earlier. Even for the la= rge providers it would be a massive operational headache.=0A= =0A= So now I'm thinking the only way to handle this thing is to know whether th= e originating domain truly has the right to claim a given caller-id number = or not for a given call. It needs to be something that's as automated as p= ossible, to reduce operational burden. And at the same time it has to avoi= d claims of prejudice if caller-ids are deemed invalid, by detecting which = specific calls are illegitimate, having a low false-positive rate, and base= d on some common ultimate authority for the numbers.=0A= =0A= It sucks because it's going to be really painful to do this stuff, whatever= we end up doing; but no one's come up with an easier way so far.=0A= :(=0A= =0A= -hadriel=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Mon Jun 24 13:24: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 7462021E817C for ; Mon, 24 Jun 2013 13:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 6fF63jwxxrrY for ; Mon, 24 Jun 2013 13:24:41 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1C21E8114 for ; Mon, 24 Jun 2013 13:24:35 -0700 (PDT) Message-ID: X-CheckPoint: {51C8AB02-10011-D2C987A5-1FFFF} From: Henning Schulzrinne To: Michael Hammer , "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J407rT0uZGkmimelssQZO+Zk/JtcAgAGhUwCAACcMgIAABXyAgAARcQCAAEPJgIAASjYAgABrIgCAAHaXgIAAGXGAgALF0Hs= Date: Mon, 24 Jun 2013 20:24:33 +0000 References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@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: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 20:24:45 -0000 We have some existence proof that numbers can be made reasonably uniform if= they have to be - I suspect SS7 isn't terribly tolerant of lots of variati= ons in either calling or called number formats, at least within a jurisdict= ion. Since most inter-provider calls touch SS7 at some point today, this se= ems analogous. (STIR is not really an issue for intra-provider calls since = the caller is a direct customer of the provider.)=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Ha= mmer [michael.hammer@yaanatech.com]=0A= Sent: Saturday, June 22, 2013 6:01 PM=0A= To: hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu=0A= Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= Those who mangle the To and From headers tend to be the sort that are too= =0A= clever for their own good.=0A= They tend to be of the hop-by-hop mind-set and don't quite get the E2E idea= =0A= of SIP.=0A= =0A= Note: Vendors can modify node behavior to do what is "right". The existin= g=0A= code base is flexible; it is software after all.=0A= The hard part is getting industry consensus on what is "right". Don't=0A= underestimate the client, PBX, or SBC vendors ability to adapt.=0A= =0A= It might be best to leave the Request-URI, To-, and Route- headers to be=0A= mangled, and not confuse that with the source identity problem.=0A= If we limited that scope, it might help keep this from trying to boil the= =0A= ocean.=0A= =0A= The tendency of folks to get too creative is what usually leads to=0A= regulation.=0A= In this case, it may come to the FCC establishing rules for those that get= =0A= number assignments directly to enforce.=0A= =0A= We should also not conflate the technical detail of ensuring validated=0A= numbers in the signaling and the legal distinction of what is spam or not.= =0A= Thanks to our legislators and the various loop-holes (political calls=0A= anyone?) that could change, we have no control of the latter, but might be= =0A= able to help with the former.=0A= Also, as noted already, there may be cases where it is permissible to send= =0A= anonymous calls that might be dependent on the called party identity,=0A= but that is an exception that should not be too hard to handle, once the=0A= basic rules are established.=0A= =0A= Mike=0A= =0A= =0A= -----Original Message-----=0A= From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of=0A= Hadriel Kaplan=0A= Sent: Saturday, June 22, 2013 4:30 PM=0A= To: Paul Kyzivat=0A= Cc: Wendt, Chris; ; Brian Rosen=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= =0A= On Jun 22, 2013, at 9:25 AM, Paul Kyzivat wrote:=0A= =0A= > *Of course* the sending operator (signer) can look at the original messag= e=0A= and figure out what the corresponding E.164 is for the caller, and probably= =0A= for the callee too. And so can use those to sign the message.=0A= >=0A= > And presumably the verifier will be able to look at the received message= =0A= and be able to figure out the E.164 number for the recipient, since it know= s=0A= where it is going to be received.=0A= >=0A= > But it is far from clear that the verifier will be able to look at the=0A= received message and be able to figure out the E.164 number for the caller.= =0A= It may just see a localized form of that number that is meaningful in the= =0A= caller's context. And without being familiar with the caller's context that= =0A= isn't enough.=0A= =0A= Ahhh - so what you're saying is that canonicalization will work for the=0A= To-number, but not the From-number. Sorry, missed that point in your=0A= original email.=0A= =0A= =0A= > STIR *could* make an assumption (requirement?) that whatever value is use= d=0A= be rewritten along the path from signer to verifier so that the verifier=0A= will be able to do the verification. But if that is the intent, then it had= =0A= better be stated with great clarity.=0A= =0A= Right, I think that is a basic assumption and we could even write it in as = a=0A= requirement. And it's not as ludicrous as it sounds to do that. For one= =0A= thing, afaict it's actually the case today. At least on SBCs, whenever I'v= e=0A= seen rewriting of the To-URI, there's a corresponding rewrite of the=0A= From-URI. In practice, operators of SIP domains do use the From-URI for=0A= stuff, so they rewrite them as they exit/enter domains.=0A= =0A= But even if it *weren't* the case, that instead a terminating domain=0A= receives a From-URI in a format it can't determine an E.164 for, then it=0A= shouldn't be displaying it as a caller-id on its subscribers' phones. So i= f=0A= the verification fails or is un-doable due to receiving such an unknown=0A= string, then arguably it's achieving the correct result: the caller-id is= =0A= unverified. Obviously at a high-level we don't *want* that to happen - we= =0A= want to be able to successfully verify legitimate caller-ids, because=0A= otherwise from the user's perspective it's a false-positive - but over time= =0A= those things will sort themselves out.=0A= =0A= That's why I was wondering if we should put a copy of the E.164 numbers int= o=0A= the Identity header, to help the operators troubleshoot failures and sort= =0A= them out.=0A= =0A= =0A= > But I continue to find this rediculous - to depend on constant rewriting= =0A= throughout the path of the message rather than canonicalizing at the=0A= endpoints. It is the antithesis of the E2E principal. (But as a precedent,= =0A= it is exactly analogous to what NATs do.)=0A= =0A= "Endpoints" have rarely ever been able to canonicalize. They have no=0A= knowledge of "contexts", or what is or is not a phone number, or what is or= =0A= is not an E.164 number vs. national vs. local vs. short code vs. star code= =0A= vs. just a string of digits. All they know is the user pressed digit=0A= buttons and a "call" or "send" button. So they just put those digits into = a=0A= SIP To-URI and req-uri user portion. And they put the AoR they Registered= =0A= into the From-URI, which again they don't know the semantics of but just us= e=0A= what they were configured to Register with.=0A= =0A= Arguably that's one of the reasons few people use 'user=3Dphone' and Tel-UR= Ls=0A= and such, and rewriting happens a lot. The RFCs assumed the endpoints were= =0A= smart - that they'd somehow know the intentions of the human and the=0A= contexts of phone numbers, and put the right things in the To/From. And=0A= then we told the Proxies not to change those To/From's, because doing that= =0A= was "evil" and subverted the endpoints' intentions. But in practice the=0A= endpoints are dumb and the 'proxies' are smart... at least for this topic= =0A= anyway. ;)=0A= =0A= -hadriel=0A= =0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From stephen.farrell@cs.tcd.ie Mon Jun 24 15:30: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 AD80621E8173 for ; Mon, 24 Jun 2013 15:30:19 -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 sujCJLcrsL3F for ; Mon, 24 Jun 2013 15:30:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B67D521E8148 for ; Mon, 24 Jun 2013 15:30:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C2EBBE7C; Mon, 24 Jun 2013 23:29:45 +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 Fa-xsA3Zmofq; Mon, 24 Jun 2013 23:29:44 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.28.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 237D8BE7B; Mon, 24 Jun 2013 23:29:44 +0100 (IST) Message-ID: <51C8C84C.3060204@cs.tcd.ie> Date: Mon, 24 Jun 2013 23:29:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> In-Reply-To: <51C89C6E.1090603@dcrocker.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stir@ietf.org" , Dave Crocker , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 22:30:19 -0000 Apologies that I've not kept fully up with this thread, esp if what I'm about to say has been said already:-) I'm not sure that the in-band/out-of-band characterisation is quite right. I'm not saying its not - I'm just not sure. I can envisage that a call from Alice to Bob via Charlie and then Dave might be such that a signature can be preserved in-band between Alice and Charlie, and between Dave and Bob, but that some out-of-band scheme might be required for the hop between Charlie and Dave. I don't know enough about the various signalling and media handling magic to know if the above is a realistic scenario or not, but if it is then the same call might require both methods, where the signature (or authorization) is sent as part of signalling messages and also where the signature (or authorization) can't be part of the signalling and some scheme like Ekr's might be needed. If that scenario is rubbish (quite possible) then no need to read further:-) If that Alice->Bob scenario is realistic and if its important enough (I've no idea) then it'd also argue to consider some aspects of the Charlie->Dave hop up front in case that'd affect how the signature ought be represented between Alice and Charlie or Alice and Bob. Or maybe that scenario is realistic but just not important at all, (again I dunno), and the WG would be better off re-chartering before taking it on. I guess this is a good topic for the BoF maybe. I think I'd agree with folks who want to first prioritise the more straightforward e2e approach that assumes that the signature can make it from Alice->Bob. S. On 06/24/2013 08:22 PM, Dave Crocker wrote: > Henning, > > > On 6/24/2013 12:08 PM, Henning Schulzrinne wrote: >> The main difference between the two STIR modes discussed is between >> the actors involved and the likely deployment incentives. The in-band >> mechanism is likely to be deployed by carriers, the out-of-band >> mechanism by end users, such as legitimate call centers (and smart > > That's quite different from what Jon confirmed for me, namely that both > would be done by the caller, every time. > > For an exercise of the type being done now, it's extremely important to > be very clear about the usage scenarios that are being proposed. > > And so, just as an example, let's say the main model is a clean, > end-to-end SIP-SIP, with an in-band authorization mechanism. but then > let's say there is a need to handle SIP-SS7-SIP, where the SS7 "hop" > might lose the authorization information. Then one can reasonably > imagine a special mechanism to handle the hop, such as stashing the > information in a side cache to be retrieved in the SS7>SIP transition. > > That's what I suggested a few days ago, but was instead told that the > intent was to have the /caller/ do /both/ mechanisms /every time/. That > is, both are being proposed as full, end-to-end mechanisms. > > At the least, it's important to get everyone sharing the same > understanding of what is being proposed, in terms of its architecture > and its usage. > > Otherwise, we really are in Wonderland. Where each person has whatever > meaning they wish and no one can communicate. Pessimal interoperability. > > >> phones), for a variety of reasons already discussed at length. I'm >> guessing that many of us are hopeful that we'll get much closer to >> 100% coverage with two mechanisms than with one. > > Unfortunately there is just as much chance -- and maybe more -- of > getting /less/. > > Having two different mechanisms creates confusion about which to use, > nevermind the added cost of everyone having to support both, which > creates a disincentive to implement either. > > >> The incremental >> validation effort is pretty minimal, and different entities have >> different incentives to deploy one or the other, possibly on >> different timelines. > > I don't think I've seen reference to "incremental" validation and am not > sure what you mean. Neither of the two mechanisms being proposed sound > incremental to me. > > > >> For example, legitimate call centers and reverse-911 operations have >> incentives to deploy out-of-band mechanisms. They can't, in most >> cases, deploy in-band solutions. >> >> Your main argument seems to be that this hasn't been done before. >> That argument seems to carry only so far, even for email. > > It's useful to know whether there is an experiential base for a > paradigm. When it exists, it helps to evaluate costs, utilities and risks. > > That doesn't preclude innovation at the level of basic paradigms, of > course, but it means that the risks are dramatically higher. > > Most new paradigms fail. > > d/ > > From michael.hammer@yaanatech.com Mon Jun 24 17:06: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 38CA321F9631 for ; Mon, 24 Jun 2013 17:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 khk7f7XI5lxv for ; Mon, 24 Jun 2013 17:06:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6A21F9947 for ; Mon, 24 Jun 2013 17:06: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; Mon, 24 Jun 2013 17:06:46 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyAgAARcACAAEPKgIAASjYAgABrIQCAAHaXgP//oHnAgACzoICAApdk4A== Date: Tue, 25 Jun 2013 00:06:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0BBFF@EX2K10MB1.corp.yaanatech.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! ! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> <31ACB2DE-0B35-4694-947F-8767C22314F4@oracle.com> In-Reply-To: <31ACB2DE-0B35-4694-947F-8767C22314F4@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0106_01CE70FD.3458BA70" MIME-Version: 1.0 Cc: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "pkyzivat@alum.mit.edu" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 00:06:58 -0000 ------=_NextPart_000_0106_01CE70FD.3458BA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You prove my point that since there is wide-spread non-standard usage for From/To, And because there is installed base inertia, Relying on those headers for anything new is a non-starter. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Saturday, June 22, 2013 6:31 PM To: Michael Hammer Cc: pkyzivat@alum.mit.edu; Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 22, 2013, at 6:01 PM, Michael Hammer wrote: > Those who mangle the To and From headers tend to be the sort that are > too clever for their own good. Umm... you mean the sort that want the calls to work? ;) > They tend to be of the hop-by-hop mind-set and don't quite get the E2E > idea of SIP. It *is* end-to-end - the rewriting is done by B2BUAs, so it's just a lot of ends. :) And to be fair, it's not every hop/node that rewrites this stuff. Usually a given domain follows a consistent format/pattern/rule-set inside its domain, as much as possible. > Note: Vendors can modify node behavior to do what is "right". The > existing code base is flexible; it is software after all. > The hard part is getting industry consensus on what is "right". Don't > underestimate the client, PBX, or SBC vendors ability to adapt. It is shockingly difficult to get vendors to change software code. Even if you get them to agree to do it, it takes a surprisingly long time. Besides, the motivation is backwards - the installed base has already sold their products and it's working, the new ones are the ones with motivation to adapt to the installed base, and that means the next round of new ones have that too, ad infinitum. And when you're a carrier, your motivation is to add sip trunks from every Enterprise, so you generally don't tell them to go switch their gear out. Likewise when peering with another carrier. Changing the To/From URI model in a SIP domain is not a small thing - it affects almost every SIP system in the domain, not to mention the back-office stuff (which is a lot of stuff). It's kinda like changing an ISP network from IPv4 to IPv6. -hadriel ------=_NextPart_000_0106_01CE70FD.3458BA70 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTAwMDY0NFowIwYJKoZIhvcNAQkEMRYEFEQvhcGAAyxwyZHrGgsScoPTwiJMMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEATdNmLn7DsdyFKzheNPEmbS/5qpMZb3Ryolw3WKi5 Zh120zzdF4ZlmN+Fx5P/JAU5nr1AJxe2HUZd9Zbk6nRMnIo8O3wt3WPMU7I1eOahkOmh0yCHrf9P NvcKk9HBWK27gQOyHFmoAkGq3rYFzqSWpHM17MaEjwfSU5uu0PLMQjmJ2HD7QX4Aorln4EIVY/Hb QnTQG2mX1X4jRxMGzPcKXmHNC9yQSRNG17hGWQw0nxUSgOq168VMG5exdLSueu2Znlhf1jBT2XS6 znO+9ylTmy8lYCZ1beS9rxfjBE+djv2OGszIaYD1/PKNdKD8aURMdFBZr6k9nfDoE03SSwD3FAAA AAAAAA== ------=_NextPart_000_0106_01CE70FD.3458BA70-- From michael.hammer@yaanatech.com Mon Jun 24 18:07: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 686DF21F9CED for ; Mon, 24 Jun 2013 18:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, 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 T7NVkqHwET2u for ; Mon, 24 Jun 2013 18:07: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 21A4B21F9CEB for ; Mon, 24 Jun 2013 18:07: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; Mon, 24 Jun 2013 18:07:34 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyAgAARcACAAEPKgIAASjYAgABrIQCAAHaXgP//oHnAgAOCqoD//9kNQA== Date: Tue, 25 Jun 2013 01:07:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0125_01CE7105.B2A2C530" MIME-Version: 1.0 Cc: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 01:07:41 -0000 ------=_NextPart_000_0125_01CE7105.B2A2C530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree so long as we stay away from dial strings or we fall of the cliff at that point. We also have to determine what it means if an E.164 is encoded as a user part followed by a domain part. Does that connote ownership or not? Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Monday, June 24, 2013 1:25 PM To: Michael Hammer; hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) We have some existence proof that numbers can be made reasonably uniform if they have to be - I suspect SS7 isn't terribly tolerant of lots of variations in either calling or called number formats, at least within a jurisdiction. Since most inter-provider calls touch SS7 at some point today, this seems analogous. (STIR is not really an issue for intra-provider calls since the caller is a direct customer of the provider.) ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Michael Hammer [michael.hammer@yaanatech.com] Sent: Saturday, June 22, 2013 6:01 PM To: hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Those who mangle the To and From headers tend to be the sort that are too clever for their own good. They tend to be of the hop-by-hop mind-set and don't quite get the E2E idea of SIP. Note: Vendors can modify node behavior to do what is "right". The existing code base is flexible; it is software after all. The hard part is getting industry consensus on what is "right". Don't underestimate the client, PBX, or SBC vendors ability to adapt. It might be best to leave the Request-URI, To-, and Route- headers to be mangled, and not confuse that with the source identity problem. If we limited that scope, it might help keep this from trying to boil the ocean. The tendency of folks to get too creative is what usually leads to regulation. In this case, it may come to the FCC establishing rules for those that get number assignments directly to enforce. We should also not conflate the technical detail of ensuring validated numbers in the signaling and the legal distinction of what is spam or not. Thanks to our legislators and the various loop-holes (political calls anyone?) that could change, we have no control of the latter, but might be able to help with the former. Also, as noted already, there may be cases where it is permissible to send anonymous calls that might be dependent on the called party identity, but that is an exception that should not be too hard to handle, once the basic rules are established. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Saturday, June 22, 2013 4:30 PM To: Paul Kyzivat Cc: Wendt, Chris; ; Brian Rosen Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 22, 2013, at 9:25 AM, Paul Kyzivat wrote: > *Of course* the sending operator (signer) can look at the original > message and figure out what the corresponding E.164 is for the caller, and probably for the callee too. And so can use those to sign the message. > > And presumably the verifier will be able to look at the received > message and be able to figure out the E.164 number for the recipient, since it knows where it is going to be received. > > But it is far from clear that the verifier will be able to look at the received message and be able to figure out the E.164 number for the caller. It may just see a localized form of that number that is meaningful in the caller's context. And without being familiar with the caller's context that isn't enough. Ahhh - so what you're saying is that canonicalization will work for the To-number, but not the From-number. Sorry, missed that point in your original email. > STIR *could* make an assumption (requirement?) that whatever value is > used be rewritten along the path from signer to verifier so that the verifier will be able to do the verification. But if that is the intent, then it had better be stated with great clarity. Right, I think that is a basic assumption and we could even write it in as a requirement. And it's not as ludicrous as it sounds to do that. For one thing, afaict it's actually the case today. At least on SBCs, whenever I've seen rewriting of the To-URI, there's a corresponding rewrite of the From-URI. In practice, operators of SIP domains do use the From-URI for stuff, so they rewrite them as they exit/enter domains. But even if it *weren't* the case, that instead a terminating domain receives a From-URI in a format it can't determine an E.164 for, then it shouldn't be displaying it as a caller-id on its subscribers' phones. So if the verification fails or is un-doable due to receiving such an unknown string, then arguably it's achieving the correct result: the caller-id is unverified. Obviously at a high-level we don't *want* that to happen - we want to be able to successfully verify legitimate caller-ids, because otherwise from the user's perspective it's a false-positive - but over time those things will sort themselves out. That's why I was wondering if we should put a copy of the E.164 numbers into the Identity header, to help the operators troubleshoot failures and sort them out. > But I continue to find this rediculous - to depend on constant > rewriting throughout the path of the message rather than canonicalizing at the endpoints. It is the antithesis of the E2E principal. (But as a precedent, it is exactly analogous to what NATs do.) "Endpoints" have rarely ever been able to canonicalize. They have no knowledge of "contexts", or what is or is not a phone number, or what is or is not an E.164 number vs. national vs. local vs. short code vs. star code vs. just a string of digits. All they know is the user pressed digit buttons and a "call" or "send" button. So they just put those digits into a SIP To-URI and req-uri user portion. And they put the AoR they Registered into the From-URI, which again they don't know the semantics of but just use what they were configured to Register with. Arguably that's one of the reasons few people use 'user=phone' and Tel-URLs and such, and rewriting happens a lot. The RFCs assumed the endpoints were smart - that they'd somehow know the intentions of the human and the contexts of phone numbers, and put the right things in the To/From. And then we told the Proxies not to change those To/From's, because doing that was "evil" and subverted the endpoints' intentions. But in practice the endpoints are dumb and the 'proxies' are smart... at least for this topic anyway. ;) -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0125_01CE7105.B2A2C530 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTAxMDczMlowIwYJKoZIhvcNAQkEMRYEFE6WUPsoREhLOS0w5bIshhijLebNMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAd7KakSGa/NDfQlQ4pIDvrkIXkoFDsAZVuQTAfA4k 4lwQ7lsnj+70I/caQ666OPO5SWCSP5sH3lS2uPtaDY1zooKVFstHo+o9COW9w2WcEKU2gfEwLNna 18AX2qaVgfmzdCnoM3SOO6Z6KA0cxNgj2goPwOY7rCcvFAeCIfFPn0sOv3zyQsbRYeq8f1gFPQg2 BeIJi3VSMMb20I+VC05wOJKXFKiGt5PNMMGLuSBFNbdrcPS4kaKXze4fGDNU+Bm/0yCf8LgR8nmr RB19Ma/IhbqShYX0BjZfod7d3i5bpPxtMPMU3LZOWKhrhuyWt68fu2RzwoZJxe5Zg1DvgwtWeQAA AAAAAA== ------=_NextPart_000_0125_01CE7105.B2A2C530-- From Henning.Schulzrinne@fcc.gov Mon Jun 24 18:39: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 6CA2711E80E4 for ; Mon, 24 Jun 2013 18:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 0bOiA7Z7dSQw for ; Mon, 24 Jun 2013 18:39: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 9E08E11E817F for ; Mon, 24 Jun 2013 18:39:46 -0700 (PDT) Message-ID: X-CheckPoint: {51C8EFB1-10003-D2C987A5-1FFFF} From: Henning Schulzrinne To: Michael Hammer , "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J407rT0uZGkmimelssQZO+Zk/JtcAgAGhUwCAACcMgIAABXyAgAARcQCAAEPJgIAASjYAgABrIgCAAHaXgIAAGXGAgALF0HuAAJLzgP//vTfH Date: Tue, 25 Jun 2013 01:17:35 +0000 References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@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: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 01:39:52 -0000 I don't see why it would necessarily. It's clear that the request URI could= just point to the next intermediary, such as an LCR or indicate temporary = reachability via an intermediary (for From).=0A= =0A= I probably missed why this would be helpful or necessary. I could see the c= ase for deriving cert location information that way ("if you get sip:TN@exa= mple.com, ask example.com for the cert for TN"), but explicit indication se= ems more general. If you just trust that AT&T would not use TN@att.com unle= ss they are the holder of the number, you're back to the trust difficulties= Hadriel has described.=0A= =0A= Thus, unlike for regular alice@example.com cases, where 'alice' is clearly = local to example.com, the use of a non-dial-string number in an inter-provi= der context would seem to indicate that this is indeed the identifier of in= terest and the domain is only a routing indicator, vaguely similar to havin= g two IP addresses in mobile IP or various identifier-locator discussions. = (Which I suspect none of us want to have on this list.)=0A= =0A= ________________________________________=0A= From: Michael Hammer [michael.hammer@yaanatech.com]=0A= Sent: Monday, June 24, 2013 9:07 PM=0A= To: Henning Schulzrinne; hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu= =0A= Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org=0A= Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= Agree so long as we stay away from dial strings or we fall of the cliff at= =0A= that point.=0A= =0A= We also have to determine what it means if an E.164 is encoded as a user=0A= part followed by a domain part.=0A= Does that connote ownership or not?=0A= =0A= Mike=0A= From pkyzivat@alum.mit.edu Mon Jun 24 21:05: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 3AF9721E805E for ; Mon, 24 Jun 2013 21:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.116, 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 sH8G40mZMV5H for ; Mon, 24 Jun 2013 21:04:59 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 423B721F8FE5 for ; Mon, 24 Jun 2013 21:04:59 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id sU2l1l0030SCNGk5DU4ye1; Tue, 25 Jun 2013 04:04:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id sU4y1l0013ZTu2S3VU4ySB; Tue, 25 Jun 2013 04:04:58 +0000 Message-ID: <51C916E9.5010406@alum.mit.edu> Date: Tue, 25 Jun 2013 00:04:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Henning Schulzrinne References: <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.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=1372133098; bh=zGIQZ3BcJVRU9L/OixjNFssFA8XTlC9HMER4HVwykUY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tiRs92rnnTW/eS82eGVFjsQRO8GZil0lmrsNSM293NdBdchTbczGh9E23xIYpU6ZF SMDqoNzTpsn9AztjWpk7lPsUEnFPv9P1tqYMVoS+p4FhpsvbxQOsOfjdJvogbSaywU o2Dry5vINqJtfQBRJx9MlvWY/8liSf9bnavcLvVvnt4KDQKe0efOyuAVjrDeFd3Oz2 lK8IKwhZuk449Zf6xbqc/+hfylYbnzx8DieZlxtR1+lB2QyRsb0za3vDPCBcnsPqLc vYp9ZMs4roPdLG1drdjL76lFQxWzG6vnH5EzoKORzSdMbG/l5GH1Zk+sWaovKmTzyu RDreaYDCGZmLA== Cc: "hadriel.kaplan@oracle.com" , "br@brianrosen.net" , Michael Hammer , "stir@ietf.org" , "Chris_Wendt@cable.comcast.com" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 04:05:05 -0000 For identification/ownership I agree. For routing, (even callback routing, to From URI) ISTM that if there is a domain, then it should be taken at least as a strong indication of preference that routing be done to that domain. That is perhaps out of scope here, except in cases where the callee saves the callerid, perhaps in an address book, for later contact. While this is outside the scope of what we can reasonably mandate, ISTM it would be useful to set expectations. Of course this is irrelevant if the recipient is incapable of handling a SIP uri. Thanks, Paul On 6/24/13 9:17 PM, Henning Schulzrinne wrote: > I don't see why it would necessarily. It's clear that the request URI could just point to the next intermediary, such as an LCR or indicate temporary reachability via an intermediary (for From). > > I probably missed why this would be helpful or necessary. I could see the case for deriving cert location information that way ("if you get sip:TN@example.com, ask example.com for the cert for TN"), but explicit indication seems more general. If you just trust that AT&T would not use TN@att.com unless they are the holder of the number, you're back to the trust difficulties Hadriel has described. > > Thus, unlike for regular alice@example.com cases, where 'alice' is clearly local to example.com, the use of a non-dial-string number in an inter-provider context would seem to indicate that this is indeed the identifier of interest and the domain is only a routing indicator, vaguely similar to having two IP addresses in mobile IP or various identifier-locator discussions. (Which I suspect none of us want to have on this list.) > > ________________________________________ > From: Michael Hammer [michael.hammer@yaanatech.com] > Sent: Monday, June 24, 2013 9:07 PM > To: Henning Schulzrinne; hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu > Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org > Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) > > Agree so long as we stay away from dial strings or we fall of the cliff at > that point. > > We also have to determine what it means if an E.164 is encoded as a user > part followed by a domain part. > Does that connote ownership or not? > > Mike > From hadriel.kaplan@oracle.com Mon Jun 24 22:18: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 0FC3711E810E for ; Mon, 24 Jun 2013 22:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 MFD6OJDX-GTg for ; Mon, 24 Jun 2013 22:18:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3068121E808F for ; Mon, 24 Jun 2013 22:18:46 -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 r5P5IcXK007632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 05:18:39 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 r5P5IacC001795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 05:18:37 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5P5IaNe011996; Tue, 25 Jun 2013 05:18:36 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-202.vpn.oracle.com (/10.154.172.202) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jun 2013 22:18: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: <51C916E9.5010406@alum.mit.edu> Date: Tue, 25 Jun 2013 01:18:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <561AA84E-DDCC-46D8-A809-E2272957BEFD@oracle.com> References: <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> <51C916E9.5010406@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" , "br@brianrosen.net" , Michael Hammer , "Chris_Wendt@cable.comcast.com" , Henning Schulzrinne Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 05:18:55 -0000 On Jun 25, 2013, at 12:04 AM, Paul Kyzivat = wrote: > For identification/ownership I agree. >=20 > For routing, (even callback routing, to =46rom URI) ISTM that if there = is a domain, then it should be taken at least as a strong indication of = preference that routing be done to that domain. That is perhaps out of = scope here, except in cases where the callee saves the callerid, perhaps = in an address book, for later contact. While this is outside the scope = of what we can reasonably mandate, ISTM it would be useful to set = expectations. This is somewhat theoretical now, but yes I agree with you that if a UAS = inside domain 'bob.com' received a request with a From-URI domain = portion of 'alice.com', it should be able to use that whole From-URI as = a To-URI later back. (or be able to use any received From-URI, for that = matter) But how is that germane to the issue at hand? By that I mean the issue = of determining an E.164 caller-id out of the received From-URI. The problem is we'd be receiving things like this: sip:12125551212@foo.com sip:2125551212@bar.com sip:+12125551212@pop.com sip:5551212@max.com Technically in SIP URI syntax, none of those are phone numbers. But = users don't perceive such received From-URIs as email addresses. They = see it as a string of digits representing a phone-number. Even if they = were shown the full URI (which is rare), I bet many users would still = perceive them as phone numbers. And other deployed systems in the = terminating provider also treat them as phone numbers - things like = voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, = etc. So if we don't try to verify it as a E.164, we'd be letting all 4 = domains above claim the same number. Then all robo-callers have to do = is delete the 'user=3Dphone' part to bypass STIR. Or I guess to put this in a different way - *if* you're going to treat = the user part as a phone number, *then* you need to canonicalize it as = an E.164. Maybe we can have some language like this: If the terminating/verifying domain treats the user part of a received = request's From-URI as a phone number for purposes of caller-id display = or processing functions, then the verification system MUST internally = generate a canonical form of the user part into the equivalent E.164 = number for the phone number it would display/process. OK? -hadriel From hadriel.kaplan@oracle.com Mon Jun 24 22:40: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 582A621E8149 for ; Mon, 24 Jun 2013 22:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 2Jp58tPbJJrJ for ; Mon, 24 Jun 2013 22:40:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C27A011E810C for ; Mon, 24 Jun 2013 22:40:08 -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 r5P5e48s024121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 05:40:05 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 r5P5e3SI019135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 05:40:04 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 r5P5e3YT019132; Tue, 25 Jun 2013 05:40:03 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-202.vpn.oracle.com (/10.154.172.202) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jun 2013 22:40:03 -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: <00C069FD01E0324C9FFCADF539701DB3BBC0BBFF@EX2K10MB1.corp.yaanatech.com> Date: Tue, 25 Jun 2013 01:40:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37618306-249D-45A4-85DF-000AABD30FF3@oracle.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! ! ! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> <31ACB2DE-0B35-4694-947F-8767C22314F4@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0BBFF@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Chris_Wendt@cable.comcast.com" , "br@brianrosen.net" , "pkyzivat@alum.mit.edu" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 05:40:15 -0000 On Jun 24, 2013, at 8:06 PM, Michael Hammer = wrote: > You prove my point that since there is wide-spread non-standard usage = for > From/To, > And because there is installed base inertia, > Relying on those headers for anything new is a non-starter. We're not relying on them - in the sense that we're not treating them as = literal strings. Instead, we're assuming the terminating domain has some means of = determining what E.614 number a received From-URI represents. -hadriel From hadriel.kaplan@oracle.com Mon Jun 24 23:00: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 5BA1221E8086 for ; Mon, 24 Jun 2013 23:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 t0WLvo65Jfx7 for ; Mon, 24 Jun 2013 23:00:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3421F9EFB for ; Mon, 24 Jun 2013 23:00:13 -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 r5P5rrmI005818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 05:53:54 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 r5P60A4q014114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 06:00:11 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5P60AGh024908; Tue, 25 Jun 2013 06:00:10 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-202.vpn.oracle.com (/10.154.172.202) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jun 2013 23:00:10 -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: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Tue, 25 Jun 2013 02:00:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: philippe.fouquart@orange.com X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 06:00:27 -0000 On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think = that grand plan could remain in scope, and again, I think the extra = flexibility for a signer is quite minimal in most dialing plans and the = added complexity for the receiver is in my view not worth it.=20 We could certainly have an RFC require the signing domain to generate a = To/=46rom URI of E.164 and 'user=3Dpart' and all, but I don't see how = that would really succeed: 1) =46rom a practical matter, legacy operators can't change all their = systems to suddenly use a new format; so you'd be forcing them to do the = signing function on their egress SBCs. While I expect that to be a = common scenario anyway, I don't think we'd want to force people to doing = it there, or on any SBCs for that matter. It should be possible to do = the signing anywhere on any system type, so long as the signing system = knows the caller can claim the E.164 number. 2) Even if the originator/signer does it that way, by the time the = terminating domain receives the call it will have come through transit = providers who already today change the To/=46rom URIs. > Finally the irony of not providing a full canonical form is that an = increasing number of user data profiles contains the subscriber number = in its full E.164 format, so it may actually require *extra work* to = provide a different format in a CgP-related header. (I'm not referring = to R-Us which in the world I live in generally have to be manipulated as = some point to see the light of the CdP party's endpoint or they'll just = never get there - if this group were to address such use cases, the = logic may have to be different IMHO) Oh you don't have to provide it in a different format - if you provide = it in an E.164 format today you can continue to with STIR, and you can = even change from your current local format to using an E.164 format. We = just wouldn't be relying on everyone changing over, for STIR to work. -hadriel From hadriel.kaplan@oracle.com Mon Jun 24 23:19: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 D5D3421E804B for ; Mon, 24 Jun 2013 23:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 zasRmI-dmv0A for ; Mon, 24 Jun 2013 23:19:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2564721F9F7C for ; Mon, 24 Jun 2013 23:19:31 -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 r5P6J7EQ023911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 06:19:08 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 r5P6J4Ga013188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 06:19:05 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5P6J3Nq013168; Tue, 25 Jun 2013 06:19:04 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-202.vpn.oracle.com (/10.154.172.202) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jun 2013 23:19:03 -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: <51C8C84C.3060204@cs.tcd.ie> Date: Tue, 25 Jun 2013 02:19:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Dave Crocker , dcrocker@bbiw.net, Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 06:19:38 -0000 On Jun 24, 2013, at 6:29 PM, Stephen Farrell = wrote: > I can envisage that a call from Alice to Bob via Charlie > and then Dave might be such that a signature can be preserved > in-band between Alice and Charlie, and between Dave and > Bob, but that some out-of-band scheme might be required > for the hop between Charlie and Dave. That depends - if it's literally just a PRI link between Charlie and = Dave, we can tunnel the info in an ISUP UUI. There're even ways of = doing that without requiring the PRI Gateway to be truly aware of it nor = need to be upgraded, depending on the vendors involved. If it's a full = SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier = connecting them, we might still be able to tunnel the UUI through. But = if it's the full-blown PSTN with multiple number of transit carriers = between Charlie and Dave, we'd likely need an out-of-band thing. The questions are: who the "we" are that would need such a thing, why we = think they'd deploy it, who we think would pay for it, where we think = they'd use it, how we think it would work, why we think it's manageable, = why we think it's scalable, etc. I know in IETF we don't always = consider those things in advance, but I think when we don't then we = waste an incredible amount of time specifying things people don't use = much. That's what happened with VIPR, TRIP, rfc4474,=20 > I don't know enough about the various signalling and > media handling magic to know if the above is a realistic > scenario or not, but if it is then the same call might > require both methods, where the signature (or > authorization) is sent as part of signalling messages > and also where the signature (or authorization) can't > be part of the signalling and some scheme like Ekr's > might be needed. It's certainly possible that Alice and Bob can't get something through = just with SIP. Some calls might require two methods, some calls might = require sixteen methods. Right now, EKRs proposal is just a high-level = concept (as I believe he intended it to be), so we can't tell whether it = will work or not, how it gets deployed, who would/would-not use it, etc. = For example, his draft proposes a common third-party = database-in-the-sky that both Alice and Bob use. Who would run this = database? Who would I contact if something broke? How does the = database know Alice can claim the E.164 number she claims? Is this = database global, that everyone on the planet need to use it for it to be = useful, or do we need to use umpteen such database providers to prove = our caller-ids? We don't always need to understand details of a proposed solution to = create a WG to work on it, but we usually want to have some idea of it's = applicability and likelihood of adoption before we do. > I guess this is a good topic for the BoF maybe. I think > I'd agree with folks who want to first prioritise the > more straightforward e2e approach that assumes that the > signature can make it from Alice->Bob. My guess is if we talk about this stuff at the BOF we're doomed - we'll = never get off the microphones and get to consensus for creating a WG. :( -hadriel From hadriel.kaplan@oracle.com Tue Jun 25 00:06: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 9A2D621F9F73 for ; Tue, 25 Jun 2013 00:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 rRjL2IeHSRHj for ; Tue, 25 Jun 2013 00:06:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 199B021F9F6D for ; Tue, 25 Jun 2013 00:06:07 -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 r5P6xhLF002934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 06:59:44 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 r5P760g9017683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 07:06:01 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5P760W9017619; Tue, 25 Jun 2013 07:06:00 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-202.vpn.oracle.com (/10.154.172.202) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 00:06:00 -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, 25 Jun 2013 03:05:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 07:06:14 -0000 On Jun 24, 2013, at 3:08 PM, Henning Schulzrinne = wrote: > The main difference between the two STIR modes discussed is between = the actors involved and the likely deployment incentives. The in-band = mechanism is likely to be deployed by carriers, the out-of-band = mechanism by end users, such as legitimate call centers (and smart = phones), for a variety of reasons already discussed at length. I'm = guessing that many of us are hopeful that we'll get much closer to 100% = coverage with two mechanisms than with one. The incremental validation = effort is pretty minimal, and different entities have different = incentives to deploy one or the other, possibly on different timelines. >=20 > For example, legitimate call centers and reverse-911 operations have = incentives to deploy out-of-band mechanisms. They can't, in most cases, = deploy in-band solutions. OK, so now we get to the heart of it. The actors involved are different = - one is for carriers, one is for smart-phone end-users and enterprises. = Those sets of actors have very different requirements, deployment = constraints, regulatory and legal issues, call volumes, and vendors. = They also typically involve different participants in the IETF, and I'm = pretty sure these two would. Yes there may be some human and documentation overlap, but we have that = across most every RAI working group. And yes we'll have to prevent = overlapping meeting times, but again we have those constraints (and = tools to handle them) already for RAI groups. But there are downsides to mixing the two together: - they either starve each other for meeting time, or one wins most of = the time and the other loses - they distract the participants who don't care about the other, e.g. = with all the emails in mailing lists such as this one - they make it hard to judge interest and consensus, because half the = group never cares about the other I suggest these two separate mechanisms be split into separate WGs. = That way an out-of-band model can be worked on without waiting for the = in-band to complete, and vice-versa. -hadriel p.s. Since 911 operators and call-centers use carriers in a similar = (albeit not identical) fashion as most Enterprises, I would expect their = carriers to be able to do the signing for them for an in-band solution. = But your point is taken, they may want to use other mechanisms - many = more than two even - at the same time. From brian.rosen@neustar.biz Tue Jun 25 05: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 563F921F96EB for ; Tue, 25 Jun 2013 05:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Mio+V2znX4Q0 for ; Tue, 25 Jun 2013 05:48:15 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A314121F9A15 for ; Tue, 25 Jun 2013 05:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372164448; x=1687509563; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=iBn+BdF9zx k8rzdRxq6XVzb8unYTNkG863uAckWK0Pk=; b=ryjelJU8a3SHfve1H3r+CyzQqx wytP3IAvvkeliwf72dDzG4DBvtZjJgCk12zlQ12Aj7NI7oOIzyxroc9GcGgQ== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21396305; Tue, 25 Jun 2013 08:47:27 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 08:48:08 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObb1Irceg+8rbrkSvrqRLwReGiJk+6X2AgAAoCYCAASNrAIAAgvYAgASasoCAAOd4AIAAcf2A Date: Tue, 25 Jun 2013 12:48:08 +0000 Message-ID: References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> In-Reply-To: <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ieN9EeSicjHkwIVZCUUCGQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <842ACC502C47CE43BCE8F8075DC6EAB9@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 12:48:20 -0000 I get that termination TN has to be able to be canonicalized, because routi= ng has to work. What do we do about From? As it is today, can the terminating domain extract a canonical e.164 from w= hat is actually sent? Alternatively, is it reasonable for the ingress SBC to rewrite it so it can= be? Or do we need to send it somewhere else? Or do we rely on P-A-I? Brian On Jun 25, 2013, at 2:00 AM, Hadriel Kaplan wro= te: >=20 > On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >> I understand it may not be the priority here but as a target I think tha= t grand plan could remain in scope, and again, I think the extra flexibilit= y for a signer is quite minimal in most dialing plans and the added complex= ity for the receiver is in my view not worth it.=20 >=20 > We could certainly have an RFC require the signing domain to generate a T= o/From URI of E.164 and 'user=3Dpart' and all, but I don't see how that wou= ld really succeed: >=20 > 1) From a practical matter, legacy operators can't change all their syste= ms to suddenly use a new format; so you'd be forcing them to do the signing= function on their egress SBCs. While I expect that to be a common scenari= o anyway, I don't think we'd want to force people to doing it there, or on = any SBCs for that matter. It should be possible to do the signing anywhere= on any system type, so long as the signing system knows the caller can cla= im the E.164 number. >=20 > 2) Even if the originator/signer does it that way, by the time the termin= ating domain receives the call it will have come through transit providers = who already today change the To/From URIs. >=20 >=20 >> Finally the irony of not providing a full canonical form is that an incr= easing number of user data profiles contains the subscriber number in its f= ull E.164 format, so it may actually require *extra work* to provide a diff= erent format in a CgP-related header. (I'm not referring to R-Us which in t= he world I live in generally have to be manipulated as some point to see th= e light of the CdP party's endpoint or they'll just never get there - if th= is group were to address such use cases, the logic may have to be different= IMHO) >=20 > Oh you don't have to provide it in a different format - if you provide it= in an E.164 format today you can continue to with STIR, and you can even c= hange from your current local format to using an E.164 format. We just wou= ldn't be relying on everyone changing over, for STIR to work. >=20 > -hadriel >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From philippe.fouquart@orange.com Tue Jun 25 05:50: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 F067A21F9F33 for ; Tue, 25 Jun 2013 05:50:07 -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, 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 wkhNS0GmigMx for ; Tue, 25 Jun 2013 05:50:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 064B321F9E18 for ; Tue, 25 Jun 2013 05:50:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id EC98E2DCFC7; Tue, 25 Jun 2013 14:49:59 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AC48B238056; Tue, 25 Jun 2013 14:49:59 +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, 25 Jun 2013 14:49:59 +0200 From: To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMIAAz44AgACHpfA= Date: Tue, 25 Jun 2013 12:49:59 +0000 Message-ID: <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> In-Reply-To: <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.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.6.25.121223 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 12:50:09 -0000 Hadriel, We seem to be talking past each other. I interpreted your comment as:=20 a) the signing of the TN - who may be done directly or on behalf of the hol= der - may use a non canonical form of TN,=20=20 b) supposing in-band, that signing would then be conveyed in some way yet T= BD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventua= lly assert authenticity.=20=20=20=20=20 My comment was that I didn't see how the verifier could reasonably do c) wi= thout prior knowledge of the numbering plan of TN, so either the signer and= the verifier implicitly share the function according to which you can tran= slate the non canonical form into a canonical form (eg they are on the same= dialing plan) or I don't see how this could work. Say TN=3D+12125551212, b= ut a) signs 2125551212 how could c) be correct unless the verifier knows th= at it's an NANP number for which adding +1 upfront is enough to make it a f= ull E.164 number?=20=20 What am I missing here?=20 I definitely don't want to force anyone doing anything with the format of t= heir CLI, I was merely observing that, with the same examples, if a) procee= ds with 2125551212 and c) is not in the NANP number or doesn't know it's an= NANP number, then I didn't see how it could determine what canonicalizatio= n function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that= grand plan could remain in scope, and again, I think the extra flexibility= for a signer is quite minimal in most dialing plans and the added complexi= ty for the receiver is in my view not worth it.=20 We could certainly have an RFC require the signing domain to generate a To/= >From URI of E.164 and 'user=3Dpart' and all, but I don't see how that would= really succeed: 1) From a practical matter, legacy operators can't change all their systems= to suddenly use a new format; so you'd be forcing them to do the signing f= unction on their egress SBCs. While I expect that to be a common scenario = anyway, I don't think we'd want to force people to doing it there, or on an= y SBCs for that matter. It should be possible to do the signing anywhere o= n any system type, so long as the signing system knows the caller can claim= the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminat= ing domain receives the call it will have come through transit providers wh= o already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an incre= asing number of user data profiles contains the subscriber number in its fu= ll E.164 format, so it may actually require *extra work* to provide a diffe= rent format in a CgP-related header. (I'm not referring to R-Us which in th= e world I live in generally have to be manipulated as some point to see the= light of the CdP party's endpoint or they'll just never get there - if thi= s group were to address such use cases, the logic may have to be different = IMHO) Oh you don't have to provide it in a different format - if you provide it i= n an E.164 format today you can continue to with STIR, and you can even cha= nge from your current local format to using an E.164 format. We just would= n't be relying on everyone changing over, for STIR to work. -hadriel ___________________________________________________________________________= ______________________________________________ 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 Tue Jun 25 05: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 C8D0221F96D9 for ; Tue, 25 Jun 2013 05:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.265 X-Spam-Level: X-Spam-Status: No, score=-100.265 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 TBfqwRcMu+82 for ; Tue, 25 Jun 2013 05:54:57 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4722311E80EC for ; Tue, 25 Jun 2013 05:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=VvM70eP59Mm5ISx0h7tVRqGallbf8VrIywhJeyK71wE=; b=WKk+xi++1HcxdJmj+s4GJNQ3HtSHr/76xQwVxO6XN2SMHlQQFL5zGnX8tu2DoDnyJtbVhocycpmC9lzbKaPIvn7gBOlq56nPtlDDdDm7vLxCF87LTVbuQ5Q71hERR0V4XaXmqL0gxbvCI4li1df9apAXo0khnl5xz/7vjyejc2U=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42384 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrSlh-0003GJ-1M; Tue, 25 Jun 2013 08:54:45 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Tue, 25 Jun 2013 08:54:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 12:55:02 -0000 I don't believe that the participants are at all different, and I don't = think the charters would be different enough to warrant two groups. I think that carriers care a lot about what devices do, and devices are = increasingly able to handle things carriers do, so while I agree with = Henning, I think the device wants to be able to check the signature if = it makes it and the carrier wants to be able to check the out of band = mechanisms on behalf of some endpoints. I don't think anyone interested = in this subject would not be on both lists and at both meetings. We're all in agreement that we will complete the in band solution before = we complete the out of band solution so it should be reasonable for = chairs to manage the WG time effectively. Brian On Jun 25, 2013, at 3:05 AM, Hadriel Kaplan = wrote: >=20 > On Jun 24, 2013, at 3:08 PM, Henning Schulzrinne = wrote: >=20 >> The main difference between the two STIR modes discussed is between = the actors involved and the likely deployment incentives. The in-band = mechanism is likely to be deployed by carriers, the out-of-band = mechanism by end users, such as legitimate call centers (and smart = phones), for a variety of reasons already discussed at length. I'm = guessing that many of us are hopeful that we'll get much closer to 100% = coverage with two mechanisms than with one. The incremental validation = effort is pretty minimal, and different entities have different = incentives to deploy one or the other, possibly on different timelines. >>=20 >> For example, legitimate call centers and reverse-911 operations have = incentives to deploy out-of-band mechanisms. They can't, in most cases, = deploy in-band solutions. >=20 >=20 > OK, so now we get to the heart of it. The actors involved are = different - one is for carriers, one is for smart-phone end-users and = enterprises. Those sets of actors have very different requirements, = deployment constraints, regulatory and legal issues, call volumes, and = vendors. They also typically involve different participants in the = IETF, and I'm pretty sure these two would. >=20 > Yes there may be some human and documentation overlap, but we have = that across most every RAI working group. And yes we'll have to prevent = overlapping meeting times, but again we have those constraints (and = tools to handle them) already for RAI groups. >=20 > But there are downsides to mixing the two together: > - they either starve each other for meeting time, or one wins most of = the time and the other loses > - they distract the participants who don't care about the other, e.g. = with all the emails in mailing lists such as this one > - they make it hard to judge interest and consensus, because half the = group never cares about the other >=20 > I suggest these two separate mechanisms be split into separate WGs. = That way an out-of-band model can be worked on without waiting for the = in-band to complete, and vice-versa. >=20 > -hadriel >=20 > p.s. Since 911 operators and call-centers use carriers in a similar = (albeit not identical) fashion as most Enterprises, I would expect their = carriers to be able to do the signing for them for an in-band solution. = But your point is taken, they may want to use other mechanisms - many = more than two even - at the same time. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Tue Jun 25 08:01: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 EDEC421F9D7F for ; Tue, 25 Jun 2013 08:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 SgsXBF3zhbJj for ; Tue, 25 Jun 2013 08:01:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DA26E21F9E42 for ; Tue, 25 Jun 2013 08:01:08 -0700 (PDT) Received: from [192.168.5.92] (ip-64-134-227-4.public.wayport.net [64.134.227.4]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5PF0nY5026178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 08:01:01 -0700 Message-ID: <51C9B09D.9040708@dcrocker.net> Date: Tue, 25 Jun 2013 08:00:45 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Rosen References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@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]); Tue, 25 Jun 2013 08:01:05 -0700 (PDT) Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band 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, 25 Jun 2013 15:01:15 -0000 On 6/25/2013 5:54 AM, Brian Rosen wrote: > We're all in agreement that we will complete the in band solution > before we complete the out of band solution so it should be > reasonable for chairs to manage the WG time effectively. Excellent! So the wg will initially focus on a pure-SIP scenario? That is: Caller SIP UA -> SIP Op1..SIP OpN -> Callee SIP UA If not, then what is the actual architectural mix of the STIR authorization service that will be targeted and how will it be handled by an pure in-band approach? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Henning.Schulzrinne@fcc.gov Tue Jun 25 08: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 6A29221F9DB5 for ; Tue, 25 Jun 2013 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 IzTea7m4MYfJ for ; Tue, 25 Jun 2013 08:09: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 561A421F9D64 for ; Tue, 25 Jun 2013 08:09:14 -0700 (PDT) Message-ID: X-CheckPoint: {51C9B299-1004D-D2C987A5-FFFF} From: Henning Schulzrinne To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J407rT0uZGkmimelssQZO+Zk/JtcAgAGhUwCAACcMgIAABXyAgAARcQCAAEPJgIAASjYAgABrIgCAAHaXgIAAGXGAgALF0HuAAJLzgP//vTfHgAB0WoCAABSQgIAAYR4p Date: Tue, 25 Jun 2013 15:09:13 +0000 References: <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> <51C916E9.5010406@alum.mit.edu>, <561AA84E-DDCC-46D8-A809-E2272957BEFD@oracle.com> In-Reply-To: <561AA84E-DDCC-46D8-A809-E2272957BEFD@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] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:09:22 -0000 I agree with the conclusion.=0A= =0A= In most non-SIP trunking cases, the call will be converted to circuit-switc= hed somewhere along the path, whether in the CO for analog trunks in tradit= ional copper-ILECs or in the FiOS box in the basement or in the cable modem= , all generating "regular" caller ID. Thus, this isn't a new problem and se= ems to be solvable in operational practice.=0A= =0A= ________________________________________=0A= From: Hadriel Kaplan [hadriel.kaplan@oracle.com]=0A= Sent: Tuesday, June 25, 2013 1:18 AM=0A= To: Paul Kyzivat=0A= Cc: Henning Schulzrinne; br@brianrosen.net; Michael Hammer; stir@ietf.org; = Chris_Wendt@cable.comcast.com=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= On Jun 25, 2013, at 12:04 AM, Paul Kyzivat wrote:= =0A= =0A= =0A= But how is that germane to the issue at hand? By that I mean the issue of = determining an E.164 caller-id out of the received From-URI.=0A= =0A= The problem is we'd be receiving things like this:=0A= sip:12125551212@foo.com=0A= sip:2125551212@bar.com=0A= sip:+12125551212@pop.com=0A= sip:5551212@max.com=0A= =0A= Technically in SIP URI syntax, none of those are phone numbers. But users = don't perceive such received From-URIs as email addresses. They see it as = a string of digits representing a phone-number. Even if they were shown th= e full URI (which is rare), I bet many users would still perceive them as p= hone numbers. And other deployed systems in the terminating provider also = treat them as phone numbers - things like voicemail servers, IVRs, CNAM ser= vers, conf bridges, billing systems, etc. So if we don't try to verify it = as a E.164, we'd be letting all 4 domains above claim the same number. The= n all robo-callers have to do is delete the 'user=3Dphone' part to bypass S= TIR.=0A= =0A= Or I guess to put this in a different way - *if* you're going to treat the = user part as a phone number, *then* you need to canonicalize it as an E.164= .=0A= =0A= Maybe we can have some language like this:=0A= If the terminating/verifying domain treats the user part of a received requ= est's From-URI as a phone number for purposes of caller-id display or proce= ssing functions, then the verification system MUST internally generate a ca= nonical form of the user part into the equivalent E.164 number for the phon= e number it would display/process.=0A= =0A= OK?=0A= =0A= -hadriel=0A= =0A= From Henning.Schulzrinne@fcc.gov Tue Jun 25 08:13: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 2168F21E80A1 for ; Tue, 25 Jun 2013 08:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 PZtGy6eOcUcY for ; Tue, 25 Jun 2013 08:13:01 -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 AFBCA21E8091 for ; Tue, 25 Jun 2013 08:13:00 -0700 (PDT) Message-ID: X-CheckPoint: {51C9B34C-1006E-D2C987A5-1FFFF} From: Henning Schulzrinne To: "philippe.fouquart@orange.com" , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiQ== Date: Tue, 25 Jun 2013 15:12:30 +0000 References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:13:05 -0000 The signed entity would always be a full E.164 number, as the theory is tha= t both calling and called carrier are able to derive that canonical format,= as they need to do today for SS7 signaling, CNAM and intercarrier compensa= tion. Thus, the originating carrier would never sign 212-555-1212, but only= +12125551212.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.f= ouquart@orange.com [philippe.fouquart@orange.com]=0A= Sent: Tuesday, June 25, 2013 8:49 AM=0A= To: Hadriel Kaplan=0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= Hadriel,=0A= =0A= We seem to be talking past each other. I interpreted your comment as:=0A= a) the signing of the TN - who may be done directly or on behalf of the hol= der - may use a non canonical form of TN,=0A= b) supposing in-band, that signing would then be conveyed in some way yet T= BD untouched to the verifier, and=0A= c) the verifier would then have to compute that "canonical form" to eventua= lly assert authenticity.=0A= =0A= My comment was that I didn't see how the verifier could reasonably do c) wi= thout prior knowledge of the numbering plan of TN, so either the signer and= the verifier implicitly share the function according to which you can tran= slate the non canonical form into a canonical form (eg they are on the same= dialing plan) or I don't see how this could work. Say TN=3D+12125551212, b= ut a) signs 2125551212 how could c) be correct unless the verifier knows th= at it's an NANP number for which adding +1 upfront is enough to make it a f= ull E.164 number?=0A= =0A= What am I missing here?=0A= =0A= I definitely don't want to force anyone doing anything with the format of t= heir CLI, I was merely observing that, with the same examples, if a) procee= ds with 2125551212 and c) is not in the NANP number or doesn't know it's an= NANP number, then I didn't see how it could determine what canonicalizatio= n function to apply.=0A= =0A= Philippe Fouquart=0A= Orange Labs Networks=0A= +33 (0) 1 45 29 58 13=0A= =0A= =0A= -----Original Message-----=0A= From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=0A= Sent: Tuesday, June 25, 2013 8:00 AM=0A= To: FOUQUART Philippe OLNC/OLN=0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= =0A= On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote:=0A= > I understand it may not be the priority here but as a target I think that= grand plan could remain in scope, and again, I think the extra flexibility= for a signer is quite minimal in most dialing plans and the added complexi= ty for the receiver is in my view not worth it.=0A= =0A= We could certainly have an RFC require the signing domain to generate a To/= >From URI of E.164 and 'user=3Dpart' and all, but I don't see how that would= really succeed:=0A= =0A= 1) From a practical matter, legacy operators can't change all their systems= to suddenly use a new format; so you'd be forcing them to do the signing f= unction on their egress SBCs. While I expect that to be a common scenario = anyway, I don't think we'd want to force people to doing it there, or on an= y SBCs for that matter. It should be possible to do the signing anywhere o= n any system type, so long as the signing system knows the caller can claim= the E.164 number.=0A= =0A= 2) Even if the originator/signer does it that way, by the time the terminat= ing domain receives the call it will have come through transit providers wh= o already today change the To/From URIs.=0A= =0A= =0A= > Finally the irony of not providing a full canonical form is that an incre= asing number of user data profiles contains the subscriber number in its fu= ll E.164 format, so it may actually require *extra work* to provide a diffe= rent format in a CgP-related header. (I'm not referring to R-Us which in th= e world I live in generally have to be manipulated as some point to see the= light of the CdP party's endpoint or they'll just never get there - if thi= s group were to address such use cases, the logic may have to be different = IMHO)=0A= =0A= Oh you don't have to provide it in a different format - if you provide it i= n an E.164 format today you can continue to with STIR, and you can even cha= nge from your current local format to using an E.164 format. We just would= n't be relying on everyone changing over, for STIR to work.=0A= =0A= -hadriel=0A= =0A= =0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc=0A= pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=0A= Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.=0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;=0A= they should not be distributed, used or copied without authorisation.=0A= If you have received this email in error, please notify the sender and dele= te this message and its attachments.=0A= As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.=0A= Thank you.=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From br@brianrosen.net Tue Jun 25 08:13: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 7BF0421E8091 for ; Tue, 25 Jun 2013 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.272 X-Spam-Level: X-Spam-Status: No, score=-100.272 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 UOhlGgRmX6Dr for ; Tue, 25 Jun 2013 08:13:01 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53021E809C for ; Tue, 25 Jun 2013 08:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=ANOeR2SsHi5pRlZajrkRRFqB2WHHxXDg39U/8rgif9w=; b=Z5kbLowy0i3cYP59VvYEdRQjjNbbXXzTj9MydRD+gy/lbDgtU84b4sofua/824uaXJAvOGPUjUkyrXJxtqXGBrdsmOnbWKRvEEh2RZR019/ZTNJle7U4nwuOwwuVy83/4xDQQCstG5SDjxg56rJKneC85FD0HSAS8NVM/zSirPw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:40149 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrUvU-0001Ge-9Y; Tue, 25 Jun 2013 11:13:00 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51C9B09D.9040708@dcrocker.net> Date: Tue, 25 Jun 2013 11:12:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78CF098B-E0BD-4690-B126-7D0EE19BACA8@brianrosen.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C9B09D.9040708@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:13:06 -0000 It doesn't have to be sip end to end to be effective. It have to be sip = to an SP that validates and does something with the results. We've = discussed, for example, requiring valid source identity as part of a = peering relationship. The in band mechanism as we have been describing it allows any element = in the path to do the validation. Brian On Jun 25, 2013, at 11:00 AM, Dave Crocker wrote: > On 6/25/2013 5:54 AM, Brian Rosen wrote: >> We're all in agreement that we will complete the in band solution >> before we complete the out of band solution so it should be >> reasonable for chairs to manage the WG time effectively. >=20 >=20 > Excellent! >=20 > So the wg will initially focus on a pure-SIP scenario? >=20 > That is: >=20 > Caller SIP UA -> SIP Op1..SIP OpN -> Callee SIP UA >=20 > If not, then what is the actual architectural mix of the STIR = authorization service that will be targeted and how will it be handled = by an pure in-band approach? >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From dhc@dcrocker.net Tue Jun 25 08:18: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 3671021F9C38 for ; Tue, 25 Jun 2013 08:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QlQMBDEfFNt for ; Tue, 25 Jun 2013 08:18:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8BD21F9D5C for ; Tue, 25 Jun 2013 08:18:34 -0700 (PDT) Received: from [192.168.5.92] (ip-64-134-227-4.public.wayport.net [64.134.227.4]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5PFIKAl026565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 08:18:30 -0700 Message-ID: <51C9B4B8.9020500@dcrocker.net> Date: Tue, 25 Jun 2013 08:18:16 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Rosen References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C9B09D.9040708@dcrocker.net> <78CF098B-E0BD-4690-B126-7D0EE19BACA8@brianrosen.net> In-Reply-To: <78CF098B-E0BD-4690-B126-7D0EE19BACA8@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Jun 2013 08:18:32 -0700 (PDT) Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band 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, 25 Jun 2013 15:18:39 -0000 On 6/25/2013 8:12 AM, Brian Rosen wrote: > It doesn't have to be sip end to end to be effective. It have to be sip to an SP that validates and does something with the results. We've discussed, for example, requiring valid source identity as part of a peering relationship. > > The in band mechanism as we have been describing it allows any element in the path to do the validation. Sure, but if it is not applied end-to-end, then what is its utility? That is, if the later stages of handling are not covered by the authorization mechanism, traffic could have arrived through a separate path, over that same final sequence, that is not protected. The processing nodes and user in that final sequence then have no way to distinguish valid from forged numbers. I'm trying to understand the system-wide trust model being proposed. d/ > > On Jun 25, 2013, at 11:00 AM, Dave Crocker wrote: >> So the wg will initially focus on a pure-SIP scenario? >> >> That is: >> >> Caller SIP UA -> SIP Op1..SIP OpN -> Callee SIP UA >> >> If not, then what is the actual architectural mix of the STIR authorization service that will be targeted and how will it be handled by an pure in-band approach? -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Tue Jun 25 08:26: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 CFC0D21E8091 for ; Tue, 25 Jun 2013 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 1a+8LaNUJUnq for ; Tue, 25 Jun 2013 08:25:56 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B8ABD21F9BC2 for ; Tue, 25 Jun 2013 08:25:56 -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, 25 Jun 2013 08:25:53 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyAgAARcACAAEPKgIAASjYAgABrIQCAAHaXgP//oHnAgAOCqoD//9kNQIAAeNKAgAB3f0A= Date: Tue, 25 Jun 2013 15:25:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0BEF1@EX2K10MB1.corp.yaanatech.com> References: <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01CE717D.9B2B7410" MIME-Version: 1.0 Cc: "Chris_Wendt@cable.comcast.com" , "stir@ietf.org" , "br@brianrosen.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:26:02 -0000 ------=_NextPart_000_0018_01CE717D.9B2B7410 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit It is a pity we don't use the Route header to actually route. Mike -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Monday, June 24, 2013 6:18 PM To: Michael Hammer; hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) I don't see why it would necessarily. It's clear that the request URI could just point to the next intermediary, such as an LCR or indicate temporary reachability via an intermediary (for From). I probably missed why this would be helpful or necessary. I could see the case for deriving cert location information that way ("if you get sip:TN@example.com, ask example.com for the cert for TN"), but explicit indication seems more general. If you just trust that AT&T would not use TN@att.com unless they are the holder of the number, you're back to the trust difficulties Hadriel has described. Thus, unlike for regular alice@example.com cases, where 'alice' is clearly local to example.com, the use of a non-dial-string number in an inter-provider context would seem to indicate that this is indeed the identifier of interest and the domain is only a routing indicator, vaguely similar to having two IP addresses in mobile IP or various identifier-locator discussions. (Which I suspect none of us want to have on this list.) ________________________________________ From: Michael Hammer [michael.hammer@yaanatech.com] Sent: Monday, June 24, 2013 9:07 PM To: Henning Schulzrinne; hadriel.kaplan@oracle.com; pkyzivat@alum.mit.edu Cc: Chris_Wendt@cable.comcast.com; br@brianrosen.net; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) Agree so long as we stay away from dial strings or we fall of the cliff at that point. We also have to determine what it means if an E.164 is encoded as a user part followed by a domain part. Does that connote ownership or not? Mike ------=_NextPart_000_0018_01CE717D.9B2B7410 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE1MjU1MlowIwYJKoZIhvcNAQkEMRYEFG51PTnhopbenuw7PW3E6Qvu6FqjMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAc9LOhUiEix1fP+/zj6E/t1c3weZsr7Xb44YuRtEs 8KvKi1OjD00wCaLjOxeWOndohhuNVBB5PDN8LOuP2udoRpQeGvHebjhojiOGgeVF6x2kP8aS5aIb birgnwz2f2V/K+AH5ltMxJitMqeSZPjHbN/48bbgZTY69PQOB+jmxWfjKHaghZzpmSSZxAF3V4w5 M7QCrgxKmcY9fJJTFSYCD8FdyraYjFj6LfO71ukjazvZ7HLlSLexhVDp9H03MQFMjUGOZCD4/qg8 aoA8BRDeg6q4GbXFc5zBvOZ6zf2VW8gAR/pnUL2oigF1gWxq6YPT8YDGyaPhf/tHKtc2g9pTewAA AAAAAA== ------=_NextPart_000_0018_01CE717D.9B2B7410-- From michael.hammer@yaanatech.com Tue Jun 25 08:30: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 17C4721F99C3 for ; Tue, 25 Jun 2013 08:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 P4kEf7ykMjOw for ; Tue, 25 Jun 2013 08:30: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 7B47621F99BC for ; Tue, 25 Jun 2013 08:30: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; Tue, 25 Jun 2013 08:30:42 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObd6J6m8qOmom8EmQkhTxasaT8pk/WSIAgAGhUwCAACcMgIAABXyAgAARcACAAEPKgIAASjYAgABrIQCAAHaXgP//oHnAgAOCqoD//9kNQIAAeNKAgAAuw4CAABSRgIAANUUQ Date: Tue, 25 Jun 2013 15:30:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0BF3B@EX2K10MB1.corp.yaanatech.com> References: <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> <51C916E9.5010406@alum.mit.edu> <561AA84E-DDCC-46D8-A809-E2272957BEFD@oracle.com> In-Reply-To: <561AA84E-DDCC-46D8-A809-E2272957BEFD@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002B_01CE717E.47852850" MIME-Version: 1.0 Cc: "stir@ietf.org" , "br@brianrosen.net" , "Chris_Wendt@cable.comcast.com" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:30:59 -0000 ------=_NextPart_000_002B_01CE717E.47852850 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hadriel, I support having some rules that make sense, but I seem to recall you saying that it will be extremely difficult to get all those SBC and PBX to change their handling of those fields. Which is it? Can we expect some rules to be imposed, or do we need to establish a new header to do this? Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Monday, June 24, 2013 10:19 PM To: Paul Kyzivat Cc: Henning Schulzrinne; br@brianrosen.net; Michael Hammer; stir@ietf.org; Chris_Wendt@cable.comcast.com Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 25, 2013, at 12:04 AM, Paul Kyzivat wrote: > For identification/ownership I agree. > > For routing, (even callback routing, to From URI) ISTM that if there is a domain, then it should be taken at least as a strong indication of preference that routing be done to that domain. That is perhaps out of scope here, except in cases where the callee saves the callerid, perhaps in an address book, for later contact. While this is outside the scope of what we can reasonably mandate, ISTM it would be useful to set expectations. This is somewhat theoretical now, but yes I agree with you that if a UAS inside domain 'bob.com' received a request with a From-URI domain portion of 'alice.com', it should be able to use that whole From-URI as a To-URI later back. (or be able to use any received From-URI, for that matter) But how is that germane to the issue at hand? By that I mean the issue of determining an E.164 caller-id out of the received From-URI. The problem is we'd be receiving things like this: sip:12125551212@foo.com sip:2125551212@bar.com sip:+12125551212@pop.com sip:5551212@max.com Technically in SIP URI syntax, none of those are phone numbers. But users don't perceive such received From-URIs as email addresses. They see it as a string of digits representing a phone-number. Even if they were shown the full URI (which is rare), I bet many users would still perceive them as phone numbers. And other deployed systems in the terminating provider also treat them as phone numbers - things like voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, etc. So if we don't try to verify it as a E.164, we'd be letting all 4 domains above claim the same number. Then all robo-callers have to do is delete the 'user=phone' part to bypass STIR. Or I guess to put this in a different way - *if* you're going to treat the user part as a phone number, *then* you need to canonicalize it as an E.164. Maybe we can have some language like this: If the terminating/verifying domain treats the user part of a received request's From-URI as a phone number for purposes of caller-id display or processing functions, then the verification system MUST internally generate a canonical form of the user part into the equivalent E.164 number for the phone number it would display/process. OK? -hadriel ------=_NextPart_000_002B_01CE717E.47852850 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE1MzA0MlowIwYJKoZIhvcNAQkEMRYEFK1xaev5ly7Td3UPCfJlp3aOwn55MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAPcmmMJ+UYC84urQh7Wxnn/dXFCMPDp0deAxtOf+C aKxozc1QLABz0E3xzq+kLvYs5tRagomN8qviJzSkGlsKMHD+/hS6/bZDXzYUYzXt9IVLPLyST84e pdszC/ra+TNf1cEi08G2TO993Zh+VoHphQUOd9aZsqzE4W3xjpR0e3HKrRQV73KXfe5974knMN65 8TdtGATfbGpH5DMQVHCrQXMuE59eOBlcks/JwMf8L96lO7fkf6iinNHz1DWgEx23bEIb6OQJuGSP 0YhlooCOHvGRi3DC6X/u3frFTR1/EIZHKHBAulgT4uVUYpolUa+/ukRJJRvmI4XNDHofPm8eDgAA AAAAAA== ------=_NextPart_000_002B_01CE717E.47852850-- From br@brianrosen.net Tue Jun 25 08:35: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 7F02321E80A1 for ; Tue, 25 Jun 2013 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.279 X-Spam-Level: X-Spam-Status: No, score=-100.279 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 U-7CwPT0+h4H for ; Tue, 25 Jun 2013 08:35:14 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id C2DE421E809F for ; Tue, 25 Jun 2013 08:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=1cOy45mDtpr3c5KqG6syEZSUcjTOsh6FZOthJEwa5KE=; b=g4dzkgjBMKbELrbB6ntmWavXARyZVqrak5qsxC4GIb4oD430nZyKuQAZoVFqESvXzZ6aELPA3Yra0nwCqdtgomTxHgaDb7/Ng2v205cPuTOnglvhEXIG+fjJTzSzDS6w3IT7GyvHHyuh/izbGt0op8d4lXMWVWJ1XZMiRDZiV6I=; Received: from neustargw.va.neustar.com ([209.173.53.233]:35217 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrVGy-00008N-KL; Tue, 25 Jun 2013 11:35:12 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <51C9B4B8.9020500@dcrocker.net> Date: Tue, 25 Jun 2013 11:35:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5392CF9F-8261-4EE0-84AF-FDC69C556B90@brianrosen.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C9B09D.9040708@dcrocker.net> <78CF098B-E0BD-4690-B126-7D0EE19BACA8@brianrosen.net> <51C9B4B8.9020500@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:35:18 -0000 The problem we are solving is robocalling, vishing and swatting. Telephone calls are typically routed through some fixed algorithm like = least cost. There isn't really a dynamic route, and there isn't a = re-route. Routing is static. While a routing hop will have alternative paths, it's only one or two = alternates usually, and only when something fails or gets congested are = the alternate paths used. As long as the peering partners of the "pink" carriers are willing to = check, and do something like making valid source identity a condition of = peering, the problem will be greatly reduced. It does not have to be = end to end to be effective. It's much better end to end, but the = mechanisms will be helpful without it. Brian On Jun 25, 2013, at 11:18 AM, Dave Crocker wrote: > On 6/25/2013 8:12 AM, Brian Rosen wrote: >> It doesn't have to be sip end to end to be effective. It have to be = sip to an SP that validates and does something with the results. We've = discussed, for example, requiring valid source identity as part of a = peering relationship. >>=20 >> The in band mechanism as we have been describing it allows any = element in the path to do the validation. >=20 > Sure, but if it is not applied end-to-end, then what is its utility? >=20 > That is, if the later stages of handling are not covered by the = authorization mechanism, traffic could have arrived through a separate = path, over that same final sequence, that is not protected. >=20 > The processing nodes and user in that final sequence then have no way = to distinguish valid from forged numbers. >=20 > I'm trying to understand the system-wide trust model being proposed. >=20 > d/ >=20 >=20 >=20 >>=20 >> On Jun 25, 2013, at 11:00 AM, Dave Crocker wrote: >>> So the wg will initially focus on a pure-SIP scenario? >>>=20 >>> That is: >>>=20 >>> Caller SIP UA -> SIP Op1..SIP OpN -> Callee SIP UA >>>=20 >>> If not, then what is the actual architectural mix of the STIR = authorization service that will be targeted and how will it be handled = by an pure in-band approach? >=20 >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From philippe.fouquart@orange.com Tue Jun 25 08:38: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 3D90811E80EE for ; Tue, 25 Jun 2013 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 E4gqCDkOauL5 for ; Tue, 25 Jun 2013 08:38:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD7911E80F2 for ; Tue, 25 Jun 2013 08:38:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7BFCD2DCE3C; Tue, 25 Jun 2013 17:38:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5AD5427C067; Tue, 25 Jun 2013 17:38:34 +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, 25 Jun 2013 17:38:34 +0200 From: To: Henning Schulzrinne , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMIAAz44AgACHpfCAABKwAIAAIlEw Date: Tue, 25 Jun 2013 15:38:33 +0000 Message-ID: <26783_1372174714_51C9B97A_26783_181_1_B5939C6860701C49AA39C5DA5189448B0A5AFC@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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.5.21.113319 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:38:40 -0000 Thank you, I would think so, and wouldn't be missing anything then: signing= for the in-band mechanism would only be done on the full E.164 form.=20 I don't know how far we want to stretch the parallel with SS7 on this thoug= h: in some SS7 networks today, the full E.164 format is never used in natio= nal calls, neither for CdP and nor CgP (the CC is not conveyed) whilst it m= ay be in others (typically >=3D 2G mobile networks).=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Tuesday, June 25, 2013 5:13 PM To: FOUQUART Philippe OLNC/OLN; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) The signed entity would always be a full E.164 number, as the theory is tha= t both calling and called carrier are able to derive that canonical format,= as they need to do today for SS7 signaling, CNAM and intercarrier compensa= tion. Thus, the originating carrier would never sign 212-555-1212, but only= +12125551212. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.f= ouquart@orange.com [philippe.fouquart@orange.com] Sent: Tuesday, June 25, 2013 8:49 AM To: Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, We seem to be talking past each other. I interpreted your comment as: a) the signing of the TN - who may be done directly or on behalf of the hol= der - may use a non canonical form of TN, b) supposing in-band, that signing would then be conveyed in some way yet T= BD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventua= lly assert authenticity. My comment was that I didn't see how the verifier could reasonably do c) wi= thout prior knowledge of the numbering plan of TN, so either the signer and= the verifier implicitly share the function according to which you can tran= slate the non canonical form into a canonical form (eg they are on the same= dialing plan) or I don't see how this could work. Say TN=3D+12125551212, b= ut a) signs 2125551212 how could c) be correct unless the verifier knows th= at it's an NANP number for which adding +1 upfront is enough to make it a f= ull E.164 number? What am I missing here? I definitely don't want to force anyone doing anything with the format of t= heir CLI, I was merely observing that, with the same examples, if a) procee= ds with 2125551212 and c) is not in the NANP number or doesn't know it's an= NANP number, then I didn't see how it could determine what canonicalizatio= n function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that= grand plan could remain in scope, and again, I think the extra flexibility= for a signer is quite minimal in most dialing plans and the added complexi= ty for the receiver is in my view not worth it. We could certainly have an RFC require the signing domain to generate a To/= >From URI of E.164 and 'user=3Dpart' and all, but I don't see how that would= really succeed: 1) From a practical matter, legacy operators can't change all their systems= to suddenly use a new format; so you'd be forcing them to do the signing f= unction on their egress SBCs. While I expect that to be a common scenario = anyway, I don't think we'd want to force people to doing it there, or on an= y SBCs for that matter. It should be possible to do the signing anywhere o= n any system type, so long as the signing system knows the caller can claim= the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminat= ing domain receives the call it will have come through transit providers wh= o already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an incre= asing number of user data profiles contains the subscriber number in its fu= ll E.164 format, so it may actually require *extra work* to provide a diffe= rent format in a CgP-related header. (I'm not referring to R-Us which in th= e world I live in generally have to be manipulated as some point to see the= light of the CdP party's endpoint or they'll just never get there - if thi= s group were to address such use cases, the logic may have to be different = IMHO) Oh you don't have to provide it in a different format - if you provide it i= n an E.164 format today you can continue to with STIR, and you can even cha= nge from your current local format to using an E.164 format. We just would= n't be relying on everyone changing over, for STIR to work. -hadriel ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ 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 timothy.dwight@verizon.com Tue Jun 25 08:49: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 C6A3211E8104 for ; Tue, 25 Jun 2013 08:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 zVQTrY81GavK for ; Tue, 25 Jun 2013 08:49:04 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id F2B7711E80F5 for ; Tue, 25 Jun 2013 08:49:00 -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; 25 Jun 2013 15:48:53 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="496568395" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 25 Jun 2013 15:48:52 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Tue, 25 Jun 2013 11:48:52 -0400 To: Henning Schulzrinne , "philippe.fouquart@orange.com" , Hadriel Kaplan Date: Tue, 25 Jun 2013 11:48:51 -0400 Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMw Message-ID: <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:49:09 -0000 What about the private dial plan / sip trunking scenarios? In that case it= may be desired to deliver the FROM header in "non-canonical" format, so th= at the recipient can know that this was an "internal" call. =20 tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hen= ning Schulzrinne Sent: Tuesday, June 25, 2013 10:13 AM To: philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) The signed entity would always be a full E.164 number, as the theory is tha= t both calling and called carrier are able to derive that canonical format,= as they need to do today for SS7 signaling, CNAM and intercarrier compensa= tion. Thus, the originating carrier would never sign 212-555-1212, but only= +12125551212. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.f= ouquart@orange.com [philippe.fouquart@orange.com] Sent: Tuesday, June 25, 2013 8:49 AM To: Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, We seem to be talking past each other. I interpreted your comment as: a) the signing of the TN - who may be done directly or on behalf of the hol= der - may use a non canonical form of TN, b) supposing in-band, that signing would then be conveyed in some way yet T= BD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventua= lly assert authenticity. My comment was that I didn't see how the verifier could reasonably do c) wi= thout prior knowledge of the numbering plan of TN, so either the signer and= the verifier implicitly share the function according to which you can tran= slate the non canonical form into a canonical form (eg they are on the same= dialing plan) or I don't see how this could work. Say TN=3D+12125551212, b= ut a) signs 2125551212 how could c) be correct unless the verifier knows th= at it's an NANP number for which adding +1 upfront is enough to make it a f= ull E.164 number? What am I missing here? I definitely don't want to force anyone doing anything with the format of t= heir CLI, I was merely observing that, with the same examples, if a) procee= ds with 2125551212 and c) is not in the NANP number or doesn't know it's an= NANP number, then I didn't see how it could determine what canonicalizatio= n function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that= grand plan could remain in scope, and again, I think the extra flexibility= for a signer is quite minimal in most dialing plans and the added complexi= ty for the receiver is in my view not worth it. We could certainly have an RFC require the signing domain to generate a To/= >From URI of E.164 and 'user=3Dpart' and all, but I don't see how that would= really succeed: 1) From a practical matter, legacy operators can't change all their systems= to suddenly use a new format; so you'd be forcing them to do the signing f= unction on their egress SBCs. While I expect that to be a common scenario = anyway, I don't think we'd want to force people to doing it there, or on an= y SBCs for that matter. It should be possible to do the signing anywhere o= n any system type, so long as the signing system knows the caller can claim= the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminat= ing domain receives the call it will have come through transit providers wh= o already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an=20 > increasing number of user data profiles contains the subscriber number=20 > in its full E.164 format, so it may actually require *extra work* to=20 > provide a different format in a CgP-related header. (I'm not referring=20 > to R-Us which in the world I live in generally have to be manipulated=20 > as some point to see the light of the CdP party's endpoint or they'll=20 > just never get there - if this group were to address such use cases,=20 > the logic may have to be different IMHO) Oh you don't have to provide it in a different format - if you provide it i= n an E.164 format today you can continue to with STIR, and you can even cha= nge from your current local format to using an E.164 format. We just would= n't be relying on everyone changing over, for STIR to work. -hadriel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ 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 Tue Jun 25 08:52: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 1F2D611E810A for ; Tue, 25 Jun 2013 08:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpNzWOof2dUz for ; Tue, 25 Jun 2013 08:51: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 B8B0311E80F5 for ; Tue, 25 Jun 2013 08:51: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, 25 Jun 2013 08:51:54 -0700 From: Michael Hammer To: "philippe.fouquart@orange.com" , "Henning.Schulzrinne@fcc.gov" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAAB0eA//+NE8A= Date: Tue, 25 Jun 2013 15:51:53 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0C06F@EX2K10MB1.corp.yaanatech.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <26783_1372174714_51C9B97A_26783_181_1_B5939C6860701C49AA39C5DA5189448B0A5AFC@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <26783_1372174714_51C9B97A_26783_181_1_B5939C6860701C49AA39C5DA5189448B0A5AFC@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004E_01CE7181.3D8D3FB0" MIME-Version: 1.0 Cc: "Brian.Rosen@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:52:07 -0000 ------=_NextPart_000_004E_01CE7181.3D8D3FB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit With overlayed area codes and number portability, I think the telephone network has evolved past the point where routing on partial numbers can be deterministic. If we can agree that we need full canonical E.164 numbers, then we have made progress. I haven't heard an argument that having a full E.164 number causes any problems. The other shoe here is whether one can tell if a sip: address has an E.164 number value as user part or not. One could argue that for this new feature to work, whatever header it operates on must be a tel: URI. But, I can't ascertain if there is the power or will to enforce that on the existing implementations. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of philippe.fouquart@orange.com Sent: Tuesday, June 25, 2013 8:39 AM To: Henning Schulzrinne; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Thank you, I would think so, and wouldn't be missing anything then: signing for the in-band mechanism would only be done on the full E.164 form. I don't know how far we want to stretch the parallel with SS7 on this though: in some SS7 networks today, the full E.164 format is never used in national calls, neither for CdP and nor CgP (the CC is not conveyed) whilst it may be in others (typically >= 2G mobile networks). Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Tuesday, June 25, 2013 5:13 PM To: FOUQUART Philippe OLNC/OLN; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) The signed entity would always be a full E.164 number, as the theory is that both calling and called carrier are able to derive that canonical format, as they need to do today for SS7 signaling, CNAM and intercarrier compensation. Thus, the originating carrier would never sign 212-555-1212, but only +12125551212. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.fouquart@orange.com [philippe.fouquart@orange.com] Sent: Tuesday, June 25, 2013 8:49 AM To: Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, We seem to be talking past each other. I interpreted your comment as: a) the signing of the TN - who may be done directly or on behalf of the holder - may use a non canonical form of TN, b) supposing in-band, that signing would then be conveyed in some way yet TBD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventually assert authenticity. My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=+12125551212, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number? What am I missing here? I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexity for the receiver is in my view not worth it. We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed: 1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs. While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on any SBCs for that matter. It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an > increasing number of user data profiles contains the subscriber number > in its full E.164 format, so it may actually require *extra work* to > provide a different format in a CgP-related header. (I'm not referring > to R-Us which in the world I live in generally have to be manipulated > as some point to see the light of the CdP party's endpoint or they'll > just never get there - if this group were to address such use cases, > the logic may have to be different IMHO) Oh you don't have to provide it in a different format - if you provide it in an E.164 format today you can continue to with STIR, and you can even change from your current local format to using an E.164 format. We just wouldn't be relying on everyone changing over, for STIR to work. -hadriel ____________________________________________________________________________ _____________________________________________ 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. _______________________________________________ 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. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_004E_01CE7181.3D8D3FB0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE1NTE1M1owIwYJKoZIhvcNAQkEMRYEFKpHV8cPZ1g3NRmXhFALp7kBsppJMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAcojOIonp9DFHkbynpLqkExAZ4F0jBjhVJZJLPOL6 dAdMEdvtSsCR2iUQm6Db+adCnxqZTV0oPMIUfbhTazH60WM5Ci8CRoPYtmL2sC/MlcHna8GAhoRl pWaN/E5gEmoIZ6McGrHsEO5IsCskLvjJHNXhNizxVbPAzJWsSnX25sPEFBO4eaY7pRzhIghTVyfJ C1t4Z/jsrRe1hlwpBY81CgM5S69mlrp9ClcZyMr8ytJbtJiJHwpmlkmHX2Hb5fo6PEleTyZ9laBD 8aBc+9amDN+Qyq4Qi9hY9wjXo88Auq3FU+U3dawI9BRLbwtJeKhjM2bO1wzRdAmEddMexz/eagAA AAAAAA== ------=_NextPart_000_004E_01CE7181.3D8D3FB0-- From michael.hammer@yaanatech.com Tue Jun 25 08:55: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 2D7C921F9808 for ; Tue, 25 Jun 2013 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX6vQh3AqCtD for ; Tue, 25 Jun 2013 08:55:38 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B49B521F95D7 for ; Tue, 25 Jun 2013 08:55:34 -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, 25 Jun 2013 08:55:34 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "Henning.Schulzrinne@fcc.gov" , "philippe.fouquart@orange.com" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieA//+L28A= Date: Tue, 25 Jun 2013 15:55:33 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0C091@EX2K10MB1.corp.yaanatech.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0053_01CE7181.C058AD80" MIME-Version: 1.0 Cc: "Brian.Rosen@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 15:55:42 -0000 ------=_NextPart_000_0053_01CE7181.C058AD80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I don't think we can specify what a private network does internally. The only question here is whether the private network should normalize, or the public network normalize the values on entry to the public network. Of course that begs the question of when is it public. One could argue that when you cross administrative domains, it becomes public. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Tuesday, June 25, 2013 8:49 AM To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) What about the private dial plan / sip trunking scenarios? In that case it may be desired to deliver the FROM header in "non-canonical" format, so that the recipient can know that this was an "internal" call. tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, June 25, 2013 10:13 AM To: philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) The signed entity would always be a full E.164 number, as the theory is that both calling and called carrier are able to derive that canonical format, as they need to do today for SS7 signaling, CNAM and intercarrier compensation. Thus, the originating carrier would never sign 212-555-1212, but only +12125551212. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.fouquart@orange.com [philippe.fouquart@orange.com] Sent: Tuesday, June 25, 2013 8:49 AM To: Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, We seem to be talking past each other. I interpreted your comment as: a) the signing of the TN - who may be done directly or on behalf of the holder - may use a non canonical form of TN, b) supposing in-band, that signing would then be conveyed in some way yet TBD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventually assert authenticity. My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=+12125551212, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number? What am I missing here? I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexity for the receiver is in my view not worth it. We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed: 1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs. While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on any SBCs for that matter. It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an > increasing number of user data profiles contains the subscriber number > in its full E.164 format, so it may actually require *extra work* to > provide a different format in a CgP-related header. (I'm not referring > to R-Us which in the world I live in generally have to be manipulated > as some point to see the light of the CdP party's endpoint or they'll > just never get there - if this group were to address such use cases, > the logic may have to be different IMHO) Oh you don't have to provide it in a different format - if you provide it in an E.164 format today you can continue to with STIR, and you can even change from your current local format to using an E.164 format. We just wouldn't be relying on everyone changing over, for STIR to work. -hadriel ____________________________________________________________________________ _____________________________________________ 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. _______________________________________________ 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_0053_01CE7181.C058AD80 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE1NTUzM1owIwYJKoZIhvcNAQkEMRYEFOTmwlb5S29xYUmFzGJZc0Bd449uMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAW3Tqj0wZNmOyA0Q3+UqYvIanH2Fr7fPvHInfsC03 xf46hnIbgQSNjJCdUW0bLmaHxr4vCUvIyYE+9jadOxi7H8vzQURb/Pwxln3e/CBVP0Vei+vgXiM2 SQm0hiKOB1LppVpIYq9M7422eY7HA/6LeH8IC9SbMXFAjdcLX/m7msIwH/1HK6XWp1Bz87O1VIrf dBCjegsXEho1fUJGEu9yWRlxkMRtSOQVKMneaUJmoQO3GmPLR7vuZEe6bDT8jnX4CoLuck1mAyxC HOepY0YHXpu/btSW/DlhN5QvDuIef7H0of7eI+B/o2jGvwfOkWOASpHIzmpyg+MueV0XqQHZtQAA AAAAAA== ------=_NextPart_000_0053_01CE7181.C058AD80-- From Henning.Schulzrinne@fcc.gov Tue Jun 25 09:36: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 95BBD21E8093 for ; Tue, 25 Jun 2013 09:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdKANyj1w0fO for ; Tue, 25 Jun 2013 09:36:02 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2421F9A41 for ; Tue, 25 Jun 2013 09:36:01 -0700 (PDT) Message-ID: X-CheckPoint: {51C9C544-10087-D2C987A5-FFFF} From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , "philippe.fouquart@orange.com" , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMwgAALLg0= Date: Tue, 25 Jun 2013 16:28:52 +0000 References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> , <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@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: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 16:36:07 -0000 Traffic that stays within a private network is probably not a major concern= , at least for the "provider-validates" scenario.=0A= My understanding is that in order to deliver usable caller ID to SIP phones= , SIP trunking providers normalize phone numbers except maybe for in-house = extensions.=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Tuesday, June 25, 2013 11:48 AM=0A= To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan=0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= What about the private dial plan / sip trunking scenarios? In that case it= may be desired to deliver the FROM header in "non-canonical" format, so th= at the recipient can know that this was an "internal" call.=0A= =0A= tim=0A= From pkyzivat@alum.mit.edu Tue Jun 25 09:38: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 F324C11E80FB for ; Tue, 25 Jun 2013 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.762 X-Spam-Level: ** X-Spam-Status: No, score=2.762 tagged_above=-999 required=5 tests=[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 YQNJoHJoRZsk for ; Tue, 25 Jun 2013 09:38:53 -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 8E39711E8118 for ; Tue, 25 Jun 2013 09:38:51 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id sbSU1l0031uE5Es5EgeqHE; Tue, 25 Jun 2013 16:38:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id sgeq1l00k3ZTu2S3cgeq3H; Tue, 25 Jun 2013 16:38:50 +0000 Message-ID: <51C9C79A.1010701@alum.mit.edu> Date: Tue, 25 Jun 2013 12:38:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> In-Reply-To: <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372178330; bh=dDSbTB/sOwwp7+TW6IBO0AEK3VIHcVAj7sWSFT3hjeY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bNh11hKSUPyt5YonhvpkNT87SkpX2hc9YU2kKmpEaUBQ7csnXg5Fw7+g8V4k1A345 scbbhpHel3PcLOj0gIxhktoeCNk4crfUiPm8UDyVS2g37UxzvH8HOcQ7SX0hrSNFYR BGM3u4XrqAVKKiTCW7+vnqoBwJLJhXUY2in2lOYyw0BRUPel6CjhXNITdUj5ondnHb MCYgu4Rif1Z34yrlN3rH76TYlCRVEO4FG3mYW8MDJwiHeu+bFWxXekf9qf0BABh04n 4gxiZ5th3Eez0mS8dwACgEYVPcjE2ckelAZsEj7g5o3v6XSmujQhcBCJDp2pdYo5oV WQaDJqUm2YDHQ== Subject: [stir] Use of UUI for 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: Tue, 25 Jun 2013 16:38:58 -0000 On 6/25/13 2:19 AM, Hadriel Kaplan wrote: > That depends - if it's literally just a PRI link between Charlie and Dave, we can tunnel the info in an ISUP UUI. There're even ways of doing that without requiring the PRI Gateway to be truly aware of it nor need to be upgraded, depending on the vendors involved. If it's a full SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier connecting them, we might still be able to tunnel the UUI through. I've seen this mentioned multiple times on this list. Let us not forget that UUI is there for others to use. We have tools.ietf.org/html/draft-ietf-cuss-sip-uui‎ that defines how to use this in SIP, and which can be tunneled in SS7. I guess this doesn't preclude using UUI for stir, but it certainly compromises it. Thanks, Paul From hadriel.kaplan@oracle.com Tue Jun 25 09: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 0689A21E8093 for ; Tue, 25 Jun 2013 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 FKQv5ni2jBGH for ; Tue, 25 Jun 2013 09:41:33 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE2511E80FB for ; Tue, 25 Jun 2013 09:41:31 -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 r5PGZ4Bm011272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 16:35:05 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 r5PGfLBC006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 16:41:21 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PGfL3k018861; Tue, 25 Jun 2013 16:41:21 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 09:41: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: Date: Tue, 25 Jun 2013 12:41:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 16:41:40 -0000 On Jun 25, 2013, at 8:54 AM, Brian Rosen wrote: > We're all in agreement that we will complete the in band solution = before we complete the out of band solution so it should be reasonable = for chairs to manage the WG time effectively. If that's truly the case - that we plan to do an in-band first, and when = that's done then an out-of-band one - then I propose we remove the = out-of-band from the charter. We can always re-charter and add new = deliverables when we're ready for an out-of-band mechanism; we = re-charter all the time in RAI groups. We might even decide by then = that an out-of-band mechanism should work very differently, or that = defining one isn't necessary, or that we don't have the right = participants in the IETF to do so successfully. For now, by removing it from the charter, we can focus on one solution = and not have to debate about this aspect during the BOF nor WG meetings. = I am very worried that we won't have a successful BOF - where I measure = "success" as reaching consensus to create a Working Group. Lengthy = microphone debates kill BOFs, in my experience. (and I recognize you and = Russ and others have seen far more BOFs than I have, so maybe I've just = been to the wrong ones ;) -hadriel From timothy.dwight@verizon.com Tue Jun 25 09:55: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 6FE3111E810D for ; Tue, 25 Jun 2013 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 ys54S3Qmewld for ; Tue, 25 Jun 2013 09:55:05 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC45B11E811E for ; Tue, 25 Jun 2013 09:54:55 -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; 25 Jun 2013 16:54:50 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="495962185" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi02.verizon.com with ESMTP; 25 Jun 2013 16:54:49 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 25 Jun 2013 12:54:48 -0400 To: Michael Hammer , "Henning.Schulzrinne@fcc.gov" , "philippe.fouquart@orange.com" , "hadriel.kaplan@oracle.com" Date: Tue, 25 Jun 2013 12:54:46 -0400 Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieA//+L28CAAA/doA== Message-ID: <2B0F677F0B95454297753F58D4A07FA30127E3E094@FHDP1LUMXC7V31.us.one.verizon.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC0C091@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0C091@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: "Brian.Rosen@neustar.biz" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 16:55:19 -0000 The scenario I meant to refer to, was one in which the private dial plan is= supported on the public network. This is commonly the case with SIP trunk= ing services. Could there be such a thing as layered signing, e.g, the Enterprise signs t= he FROM header (if it wants) and the public network signs the P-Asserted-Id= entity header. PAID is not necessarily a canonical version of the FROM hea= der, it is simply an identity assigned by the network. It doesn't have to = be in International E.164 format but in practice it normally is. tim -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Tuesday, June 25, 2013 10:56 AM To: Dwight, Timothy M (Tim); Henning.Schulzrinne@fcc.gov; philippe.fouquart= @orange.com; hadriel.kaplan@oracle.com Cc: Brian.Rosen@neustar.biz; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) I don't think we can specify what a private network does internally. The only question here is whether the private network should normalize,=20 or the public network normalize the values on entry to the public network. Of course that begs the question of when is it public. One could argue that when you cross administrative domains, it becomes public. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Tuesday, June 25, 2013 8:49 AM To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) What about the private dial plan / sip trunking scenarios? In that case it may be desired to deliver the FROM header in "non-canonical" format, so tha= t the recipient can know that this was an "internal" call. =20 tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Tuesday, June 25, 2013 10:13 AM To: philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) The signed entity would always be a full E.164 number, as the theory is tha= t both calling and called carrier are able to derive that canonical format, a= s they need to do today for SS7 signaling, CNAM and intercarrier compensation= . Thus, the originating carrier would never sign 212-555-1212, but only +12125551212. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.fouquart@orange.com [philippe.fouquart@orange.com] Sent: Tuesday, June 25, 2013 8:49 AM To: Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, We seem to be talking past each other. I interpreted your comment as: a) the signing of the TN - who may be done directly or on behalf of the holder - may use a non canonical form of TN, b) supposing in-band, that signing would then be conveyed in some way yet TBD untouched to the verifier, and c) the verifier would then have to compute that "canonical form" to eventually assert authenticity. My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=3D+1212555121= 2, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number? What am I missing here? I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply. Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Tuesday, June 25, 2013 8:00 AM To: FOUQUART Philippe OLNC/OLN Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexit= y for the receiver is in my view not worth it. We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=3Dpart' and all, but I don't see how that wo= uld really succeed: 1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs. While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on an= y SBCs for that matter. It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number. 2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs. > Finally the irony of not providing a full canonical form is that an=20 > increasing number of user data profiles contains the subscriber number=20 > in its full E.164 format, so it may actually require *extra work* to=20 > provide a different format in a CgP-related header. (I'm not referring=20 > to R-Us which in the world I live in generally have to be manipulated=20 > as some point to see the light of the CdP party's endpoint or they'll=20 > just never get there - if this group were to address such use cases,=20 > the logic may have to be different IMHO) Oh you don't have to provide it in a different format - if you provide it i= n an E.164 format today you can continue to with STIR, and you can even chang= e from your current local format to using an E.164 format. We just wouldn't be relying on everyone changing over, for STIR to work. -hadriel ___________________________________________________________________________= _ _____________________________________________ 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. _______________________________________________ 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 pkyzivat@alum.mit.edu Tue Jun 25 09:57: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 6874811E8122 for ; Tue, 25 Jun 2013 09:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.462 X-Spam-Level: ** X-Spam-Status: No, score=2.462 tagged_above=-999 required=5 tests=[AWL=0.300, 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 jP4EZ6wXH5JU for ; Tue, 25 Jun 2013 09:56:44 -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 8CD6D21E8093 for ; Tue, 25 Jun 2013 09:56:43 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id se2D1l0021ei1Bg51gwf11; Tue, 25 Jun 2013 16:56:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id sgwf1l0083ZTu2S3kgwffy; Tue, 25 Jun 2013 16:56:39 +0000 Message-ID: <51C9CBC6.6050003@alum.mit.edu> Date: Tue, 25 Jun 2013 12:56:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51C33699.9000308@alum.mit.edu> <0E1AD635-79F1-4D08-8C75-0DF65A56511C@brianrosen.net> <2A84EE00-5749-464F-A3CB-DE7083F6B281@brianrosen.net> <1E0475FDD84F0C42A9F46570BB946FD94192E9CA@PACDCEXMB01.cable.comcast.com> <51C4A0D6.1000903@alum.mit.edu> <51C4C631.2000802@alum.mit.edu> <60B1B874-168B-40EE-8F7F-3F9E6907A0B5@oracle.com> <51C50DAF.40006@alum.mit.edu> <39DAF034-BC69-44A0-9034-D646AFC50283@oracle.com> <51C5A5CE.2050906@alum.mit.ed! u> <81B2F6EF-6D1C-4C33-980F-250CA01EA3B5@oracle.com>, <00C069FD01E0324C9FFCADF539701DB3BBC0B1F3@EX2K10MB1.corp.yaanatech.com> , <00C069FD01E0324C9FFCADF539701DB3BBC0BD3C@EX2K10MB1.corp.yaanatech.com> <51C916E9.5010406@alum.mit.edu> <561AA84E-DDCC-46D8-A809-E2272957BEFD@oracle.com> In-Reply-To: <561AA84E-DDCC-46D8-A809-E2272957BEFD@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=1372179399; bh=YMZ4bv3nJDOnNkvFXog6XfLG2mRHtD6PMiMIYC5KoCk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jTjRvd1GZeVCQDHJ3sxpzl+0dbiYhHG3XYUuMgvjeWzQDo4jEUD92bHnvvKgDZmeP 9ajmwlh7VrCgHhbK0CWo4lzU3yUD9/0usk3hegOWUMxyqeLow0oPW9fGXX0VvsXm5i Fue/l00O6aF6+c1L2weTShHUJSaRNBNRPVN17yD37CaLvnpmIyWOnPOOyNrE1UwJzC q679euNuwv845UuiSkFx7KdLaOgEyRrl4lQkvi6+NiNBXnxylZ8VVC9JTRuUqjZnAw gsDi+b9oyMTTTIgnjB6Nu3xIMid9o9/7qxF4AwqkTLdc5nvf+rzl4VaTUz37PTMuc1 BpfoMUcHuDreA== Cc: "stir@ietf.org" , "br@brianrosen.net" , Michael Hammer , "Chris_Wendt@cable.comcast.com" , Henning Schulzrinne Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 16:57:15 -0000 On 6/25/13 1:18 AM, Hadriel Kaplan wrote: > > On Jun 25, 2013, at 12:04 AM, Paul Kyzivat wrote: > >> For identification/ownership I agree. >> >> For routing, (even callback routing, to From URI) ISTM that if there is a domain, then it should be taken at least as a strong indication of preference that routing be done to that domain. That is perhaps out of scope here, except in cases where the callee saves the callerid, perhaps in an address book, for later contact. While this is outside the scope of what we can reasonably mandate, ISTM it would be useful to set expectations. > > > This is somewhat theoretical now, but yes I agree with you that if a UAS inside domain 'bob.com' received a request with a From-URI domain portion of 'alice.com', it should be able to use that whole From-URI as a To-URI later back. (or be able to use any received From-URI, for that matter) > > But how is that germane to the issue at hand? By that I mean the issue of determining an E.164 caller-id out of the received From-URI. I agree that it is somewhat off-topic, though "related". When I capture a caller's "number" to save in my address book, if it is actually a SIP URI, then ideally that would be captured in my address book, so that when I call it later the domain will be used. But of course that only makes sense if the domain is "right". If the domain I receive is just a matter of convenience based on the last provider it passed through, then I would be better off not capturing it. Whether it *matters* depends on whether the user with that number gets value out of having calls routed via sip. So it would be good for the caller to have the option to indicate whether it is or isn't. And that is where TEL comes in: If you don't care how it is routed, use TEL; if you do, use SIP. (In From.) And of course, if the call transits a non-sip leg, then the distinction will be lost. Sad, but a limitation of the deployed technology. Regardless of this, we can still sign based on the E.164 in or derived from the From-URI. Thanks, Paul > The problem is we'd be receiving things like this: > sip:12125551212@foo.com > sip:2125551212@bar.com > sip:+12125551212@pop.com > sip:5551212@max.com > > Technically in SIP URI syntax, none of those are phone numbers. But users don't perceive such received From-URIs as email addresses. They see it as a string of digits representing a phone-number. Even if they were shown the full URI (which is rare), I bet many users would still perceive them as phone numbers. And other deployed systems in the terminating provider also treat them as phone numbers - things like voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, etc. So if we don't try to verify it as a E.164, we'd be letting all 4 domains above claim the same number. Then all robo-callers have to do is delete the 'user=phone' part to bypass STIR. > > Or I guess to put this in a different way - *if* you're going to treat the user part as a phone number, *then* you need to canonicalize it as an E.164. > > Maybe we can have some language like this: > If the terminating/verifying domain treats the user part of a received request's From-URI as a phone number for purposes of caller-id display or processing functions, then the verification system MUST internally generate a canonical form of the user part into the equivalent E.164 number for the phone number it would display/process. > > OK? > > -hadriel > > From dhc@dcrocker.net Tue Jun 25 10:00: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 7F2D921F9942 for ; Tue, 25 Jun 2013 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 0fli03W3-+vF for ; Tue, 25 Jun 2013 10:00:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D607521E80A3 for ; Tue, 25 Jun 2013 10:00:31 -0700 (PDT) Received: from [192.168.5.202] (ip-64-134-230-63.public.wayport.net [64.134.230.63]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5PH0EKt028542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 10:00:23 -0700 Message-ID: <51C9CC99.7020007@dcrocker.net> Date: Tue, 25 Jun 2013 10:00:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> In-Reply-To: <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Jun 2013 10:00:28 -0700 (PDT) Cc: "stir@ietf.org" , Henning Schulzrinne , "dcrocker@bbiw.net" , Brian Rosen Subject: Re: [stir] Out-of-band vs. in-band 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, 25 Jun 2013 17:00:37 -0000 > If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF to do so successfully. > > For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just been to the wrong ones ;) +1. Narrow, clear focus. Good. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Tue Jun 25 10:00: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 90C6021F93BA for ; Tue, 25 Jun 2013 10:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553, 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 cv4-CoJK0Y9X for ; Tue, 25 Jun 2013 10:00:55 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20121F9A1D for ; Tue, 25 Jun 2013 10:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372180151; x=1687539202; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=E4GLSSES+F RSM28E8V7avj1gt7rt9ektNOfUgUGrMpU=; b=jNlHMMiI/y1ukcoOsmBwRI8Rb7 Gv9brOXuTpUXn836+KfgD46hPqVlD2HigY0JvCYbckpMruNINrPgvmhrrJFQ== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26840934; Tue, 25 Jun 2013 13:09:10 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 13:00:48 -0400 From: "Rosen, Brian" To: "Dwight, Timothy M (Tim)" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObb1Irceg+8rbrkSvrqRLwReGiJk+6X2AgAAoCYCAASNrAIAAgvYAgASasoCAAOd4AIAAcoKAgAAn0gCAAAoogIAAAd+AgAAQjACAAAGtAA== Date: Tue, 25 Jun 2013 17:00:47 +0000 Message-ID: <1DBA45F9-D3B4-471B-9965-D3343D7201D6@neustar.biz> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <00C069FD01E0324C9FFCADF539701DB3BBC0C091@EX2K10MB1.corp.yaanatech.com> <2B0F677F0B95454297753F58D4A07FA30127E3E094@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3E094@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oZ/2Hwg+wgfjKglDO8iADA== Content-Type: text/plain; charset="us-ascii" Content-ID: <00C730BD258EB84280DD4200E560394B@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , Michael Hammer , "hadriel.kaplan@oracle.com" , "stir@ietf.org" , "Henning.Schulzrinne@fcc.gov" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:00:59 -0000 > Could there be such a thing as layered signing, e.g, the Enterprise signs= the FROM header (if it wants) and the public network signs the P-Asserted-= Identity header. PAID is not necessarily a canonical version of the FROM h= eader, it is simply an identity assigned by the network. It doesn't have t= o be in International E.164 format but in practice it normally is. >=20 I think this is a fall back. We'd like the in band mechanism to be able to= be end to end, even if that isn't the way it's initially deployed. P-A-I = isn't end to end. But if From can't be canonicalized at the termination, we have to do someth= ing. There seems to be two ways to handle the case where From can't be canonical= ized, three really, if rewrite at ingress SBC is an option: a) Sign on a canonicalized PAI b) Send the canonicalized From in a (new) header, possibly as a parameter t= o the identity header. Brian= From timothy.dwight@verizon.com Tue Jun 25 10:03: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 F299521E8099 for ; Tue, 25 Jun 2013 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 cH7mE5AMC93E for ; Tue, 25 Jun 2013 10:02:53 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 026AC21E8091 for ; Tue, 25 Jun 2013 10:02:52 -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; 25 Jun 2013 17:02:52 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="504307129" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 25 Jun 2013 17:02:51 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 25 Jun 2013 13:02:51 -0400 To: Henning Schulzrinne , "philippe.fouquart@orange.com" , Hadriel Kaplan Date: Tue, 25 Jun 2013 13:02:50 -0400 Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMwgAALLg2AAAieAA== Message-ID: <2B0F677F0B95454297753F58D4A07FA30127E3E0A6@FHDP1LUMXC7V31.us.one.verizon.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> , <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@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: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:03:00 -0000 So you're proposing that SIP trunking services would be exempted from these= requirements? That's one solution I suppose. I'm not opposed. You may have more experience that me with SIP trunking services, but in my = limited experience the PBX often needs to know (or at least, will behave di= fferently if it knows) that the call was from an on-net user. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Tuesday, June 25, 2013 11:29 AM To: Dwight, Timothy M (Tim); philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) Traffic that stays within a private network is probably not a major concern= , at least for the "provider-validates" scenario. My understanding is that in order to deliver usable caller ID to SIP phones= , SIP trunking providers normalize phone numbers except maybe for in-house = extensions. ________________________________________ From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] Sent: Tuesday, June 25, 2013 11:48 AM To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) What about the private dial plan / sip trunking scenarios? In that case it= may be desired to deliver the FROM header in "non-canonical" format, so th= at the recipient can know that this was an "internal" call. tim From hadriel.kaplan@oracle.com Tue Jun 25 10:03: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 B61A721E80A3 for ; Tue, 25 Jun 2013 10:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[AWL=0.999, 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 y0jXhhMETPED for ; Tue, 25 Jun 2013 10:03:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07721E80AD for ; Tue, 25 Jun 2013 10:03:14 -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 r5PGurAH006426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 16:56:54 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 r5PH3ADs027160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 17:03:11 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PH3A2s014414; Tue, 25 Jun 2013 17:03:10 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 10:03:10 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C9C79A.1010701@alum.mit.edu> Date: Tue, 25 Jun 2013 13:03:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@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] Use of UUI for 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: Tue, 25 Jun 2013 17:03:21 -0000 On Jun 25, 2013, at 12:38 PM, Paul Kyzivat = wrote: > On 6/25/13 2:19 AM, Hadriel Kaplan wrote: >=20 >> That depends - if it's literally just a PRI link between Charlie and = Dave, we can tunnel the info in an ISUP UUI. There're even ways of = doing that without requiring the PRI Gateway to be truly aware of it nor = need to be upgraded, depending on the vendors involved. If it's a full = SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier = connecting them, we might still be able to tunnel the UUI through. >=20 > I've seen this mentioned multiple times on this list. >=20 > Let us not forget that UUI is there for others to use. > We have tools.ietf.org/html/draft-ietf-cuss-sip-uui=E2=80=8E that = defines how to use this in SIP, and which can be tunneled in SS7. >=20 > I guess this doesn't preclude using UUI for stir, but it certainly = compromises it. Right, it doesn't preclude use of it for STIR, but it does mean the UUI = may already be being used by another element for the given INVITE/IAM = message. But I'm not sure or not if that will present a real problem in = practice. For a direct PRI link between two SIP carriers/service-providers, I've = been told that's not really a problem - UUI isn't used nor useful on = such links typically. I don't have much real-world experience seeing = what crosses such links, but from what I hear we'd be ok in using UUI = there. But we'd need to ask some experts who know. For an SS7 carrier, I've been told the main use of UUI is for = Enterprises which communicate amongst their branch offices, using the = UUI between their HQ and branch PBXs across the SS7 carrier. It = sometimes goes across multiple SS7 carriers, but not as much as staying = only within one carrier as a transport between the PRIs of an = Enterprise. Realistically the UUI is not used between participants who = don't know each other in-advance, because UUI is a proprietary blob and = both ends need to use the same PBX vendor/products to understand the = UUI. If that's the case, I think we might be ok. Because for an Enterprise = communicating to its carrier using PRIs, STIR isn't necessary/needed = when its talking to its own branch offices and using the UUI. When it = communicates to others, it doesn't send a UUI so we're free to use it. That's my theory anyway, from what I hear about its use - but as I said = we'd need to ask some people who deal with that stuff on a daily basis. -hadriel From pkyzivat@alum.mit.edu Tue Jun 25 10: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 22CC021E8091 for ; Tue, 25 Jun 2013 10:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=1.450, 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 lsBd7-mKRRdL for ; Tue, 25 Jun 2013 10:05:08 -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 43EF321E80B2 for ; Tue, 25 Jun 2013 10:05:07 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id saxy1l0021YDfWL5Ah57ht; Tue, 25 Jun 2013 17:05:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id sh571l00N3ZTu2S3gh57Aj; Tue, 25 Jun 2013 17:05:07 +0000 Message-ID: <51C9CDC2.80106@alum.mit.edu> Date: Tue, 25 Jun 2013 13:05:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.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=1372179907; bh=/RYOwzh5lobM+ZYAjtbn3iBlAVaVDzRfHlYl5bpNiME=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nIKcH1AUm57MZYd4XFuBECumGT0nwX2CEcod+9D7gVOE2MiU6v7fvULQyMxcKcaWi l9dTh7vk+PfYqPERdhyDexyItIt5DZOECdUk5pRbGWFXzuqiBnraxiXnT8sOu1WkYx euoxnIsEorf1EVc4yYE4Zxtj1KJY5tewfR+G/Az0mjMAjEQ/Hx5Tk7vHtQOyECi+02 BLujE0TqCm5v0BHD4/oSiUl7gHBFU9+psFb0fCEDEwiCJfgsVZ1mwJIXZOWBqc2A5T YOY/aWtzAr0YF4SkHCVQBcvWFA1JfSPX3AJfR3vyRgSZAt+JBFCuS2Vsa8/e/JAsR4 bRt33oF+zYLWw== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:05:13 -0000 On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: > What about the private dial plan / sip trunking scenarios? In that case it may be desired to deliver the FROM header in "non-canonical" format, so that the recipient can know that this was an "internal" call. I have never understood this argument. If the call is "internal" (because the caller and callee are in the same enterprise, regardless of whether the call transited a public hop), then the recipient should be able to recognize that the From, in E.164 format, is an internal number. If it wants, the receiving device can apply the inverse of the dial plan to the number to produce an internal dial string that represents the caller, and display that as the caller id. I have experienced behavior such as you describe, that worked poorly, because individual sites of the enterprise have different dial plans, so that the "local" number at one site has a different meaning when displayed as caller id for the callee at a different site. If the calling number has no E.164 equivalent, then the telephone-subscriber syntax used in both TEL and SIP has a phone-context param that can be used to represent the private number in a globally unique way. Thanks, Paul > tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne > Sent: Tuesday, June 25, 2013 10:13 AM > To: philippe.fouquart@orange.com; Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > The signed entity would always be a full E.164 number, as the theory is that both calling and called carrier are able to derive that canonical format, as they need to do today for SS7 signaling, CNAM and intercarrier compensation. Thus, the originating carrier would never sign 212-555-1212, but only +12125551212. > > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of philippe.fouquart@orange.com [philippe.fouquart@orange.com] > Sent: Tuesday, June 25, 2013 8:49 AM > To: Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > Hadriel, > > We seem to be talking past each other. I interpreted your comment as: > a) the signing of the TN - who may be done directly or on behalf of the holder - may use a non canonical form of TN, > b) supposing in-band, that signing would then be conveyed in some way yet TBD untouched to the verifier, and > c) the verifier would then have to compute that "canonical form" to eventually assert authenticity. > > My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=+12125551212, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number? > > What am I missing here? > > I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply. > > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Tuesday, June 25, 2013 8:00 AM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >> I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexity for the receiver is in my view not worth it. > > We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed: > > 1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs. While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on any SBCs for that matter. It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number. > > 2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs. > > >> Finally the irony of not providing a full canonical form is that an >> increasing number of user data profiles contains the subscriber number >> in its full E.164 format, so it may actually require *extra work* to >> provide a different format in a CgP-related header. (I'm not referring >> to R-Us which in the world I live in generally have to be manipulated >> as some point to see the light of the CdP party's endpoint or they'll >> just never get there - if this group were to address such use cases, >> the logic may have to be different IMHO) > > Oh you don't have to provide it in a different format - if you provide it in an E.164 format today you can continue to with STIR, and you can even change from your current local format to using an E.164 format. We just wouldn't be relying on everyone changing over, for STIR to work. > > -hadriel > > > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > 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 pkyzivat@alum.mit.edu Tue Jun 25 10:12: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 F3D1B11E811E for ; Tue, 25 Jun 2013 10:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.829 X-Spam-Level: X-Spam-Status: No, score=0.829 tagged_above=-999 required=5 tests=[AWL=0.666, 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 L0dF6LRQRXJN for ; Tue, 25 Jun 2013 10:12:18 -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 AB2AD11E811D for ; Tue, 25 Jun 2013 10:12:17 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id sc6u1l0021wpRvQ55hCHC2; Tue, 25 Jun 2013 17:12:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id shCG1l0163ZTu2S3ehCHpJ; Tue, 25 Jun 2013 17:12:17 +0000 Message-ID: <51C9CF6F.3060907@alum.mit.edu> Date: Tue, 25 Jun 2013 13:12:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372180337; bh=F6roQp67bP4pjU19dGbFAn5N+3vB8Yijek1sPVjtx24=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YLJKDfoMuj4Ax+3Zlm00aT/gz8y0ftPo+PBmljeHgfLAIPL8QIHe9esRfBBKM7QQ7 HnNEhXOt3QWhbDcROagrf0vGo36rjVIZwOo641aEPKcE2OfBxVmuOgtHA+Sjdly1+f UXqjAScEp75EAn5J/zsDaxwj20qp0WngMrcg2lPoptLySdKlmf58uoicDvi66w0E29 Gx85jt5sAlc01xja3vhjC9Vk7Ui7s1vDIyN804kGPmpc/9AuzQhVi811eSsnejAZ93 4lZVlVb3d52yDefdt63Sbf9sekQ6NemIFKdmZvtA8YUb+kyQJ+bzDNkhy+6m1TCXEI MlB14COGGE7hQ== Cc: stir@ietf.org Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 17:12:23 -0000 When UUI is used in SIP, there are other parameters available to describe the purpose. On the non-sip links there is only the one byte prefix, which isn't really helpful for anything. And AFAIK there are no standards for what the rest looks like. So there is the possibility of misunderstanding the purpose of a received UUI. That must also be taken into account. Combine that with the lack of universal support for UUI, and maybe it just isn't something that makes sense to use for stir. Thanks, Paul On 6/25/13 1:03 PM, Hadriel Kaplan wrote: > > On Jun 25, 2013, at 12:38 PM, Paul Kyzivat wrote: > >> On 6/25/13 2:19 AM, Hadriel Kaplan wrote: >> >>> That depends - if it's literally just a PRI link between Charlie and Dave, we can tunnel the info in an ISUP UUI. There're even ways of doing that without requiring the PRI Gateway to be truly aware of it nor need to be upgraded, depending on the vendors involved. If it's a full SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier connecting them, we might still be able to tunnel the UUI through. >> >> I've seen this mentioned multiple times on this list. >> >> Let us not forget that UUI is there for others to use. >> We have tools.ietf.org/html/draft-ietf-cuss-sip-uui‎ that defines how to use this in SIP, and which can be tunneled in SS7. >> >> I guess this doesn't preclude using UUI for stir, but it certainly compromises it. > > Right, it doesn't preclude use of it for STIR, but it does mean the UUI may already be being used by another element for the given INVITE/IAM message. But I'm not sure or not if that will present a real problem in practice. > > For a direct PRI link between two SIP carriers/service-providers, I've been told that's not really a problem - UUI isn't used nor useful on such links typically. I don't have much real-world experience seeing what crosses such links, but from what I hear we'd be ok in using UUI there. But we'd need to ask some experts who know. > > For an SS7 carrier, I've been told the main use of UUI is for Enterprises which communicate amongst their branch offices, using the UUI between their HQ and branch PBXs across the SS7 carrier. It sometimes goes across multiple SS7 carriers, but not as much as staying only within one carrier as a transport between the PRIs of an Enterprise. Realistically the UUI is not used between participants who don't know each other in-advance, because UUI is a proprietary blob and both ends need to use the same PBX vendor/products to understand the UUI. > > If that's the case, I think we might be ok. Because for an Enterprise communicating to its carrier using PRIs, STIR isn't necessary/needed when its talking to its own branch offices and using the UUI. When it communicates to others, it doesn't send a UUI so we're free to use it. > > That's my theory anyway, from what I hear about its use - but as I said we'd need to ask some people who deal with that stuff on a daily basis. > > -hadriel > > From timothy.dwight@verizon.com Tue Jun 25 10: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 8C47021F9A03 for ; Tue, 25 Jun 2013 10:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.866, 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 4G+GimWQkgAg for ; Tue, 25 Jun 2013 10:15:51 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id D9DF511E8114 for ; Tue, 25 Jun 2013 10:15:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 25 Jun 2013 17:15:49 +0000 From: "Dwight, Timothy M \(Tim\)" X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="496641564" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 25 Jun 2013 17:15:49 +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, 25 Jun 2013 13:15:49 -0400 To: Paul Kyzivat , "stir@ietf.org" Date: Tue, 25 Jun 2013 13:15:48 -0400 Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: Ac5xxkCNrh54jRSxSK2WWnUNWuJwYwAAJ8MQ Message-ID: <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> In-Reply-To: <51C9CDC2.80106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:15:56 -0000 It's not just an issue of what gets displayed. The PBX may have different = policies for internal and external calls. It's not necessarily the case th= at every PBX in an Enterprise knows the E.164 numbers of every other PBX in= the Enterprise. That's why they have private dial plans... I won't comment on what works poorly or well, other than to note that most = solutions can be made to fall into either category. This may all be moot if it's agreed to exclude calls that originate and ter= minate within the same Enterprise, from this activity. Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Tuesday, June 25, 2013 12:05 PM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: > What about the private dial plan / sip trunking scenarios? In that case = it may be desired to deliver the FROM header in "non-canonical" format, so = that the recipient can know that this was an "internal" call. I have never understood this argument. If the call is "internal" (because the caller and callee are in the same en= terprise, regardless of whether the call transited a public hop), then the = recipient should be able to recognize that the From, in E.164 format, is an= internal number. If it wants, the receiving device can apply the inverse o= f the dial plan to the number to produce an internal dial string that repre= sents the caller, and display that as the caller id. I have experienced behavior such as you describe, that worked poorly, becau= se individual sites of the enterprise have different dial plans, so that th= e "local" number at one site has a different meaning when displayed as call= er id for the callee at a different site. If the calling number has no E.164 equivalent, then the telephone-subscribe= r syntax used in both TEL and SIP has a phone-context param that can be use= d to represent the private number in a globally unique way. Thanks, Paul > tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Henning Schulzrinne > Sent: Tuesday, June 25, 2013 10:13 AM > To: philippe.fouquart@orange.com; Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > The signed entity would always be a full E.164 number, as the theory is t= hat both calling and called carrier are able to derive that canonical forma= t, as they need to do today for SS7 signaling, CNAM and intercarrier compen= sation. Thus, the originating carrier would never sign 212-555-1212, but on= ly +12125551212. > > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of=20 > philippe.fouquart@orange.com [philippe.fouquart@orange.com] > Sent: Tuesday, June 25, 2013 8:49 AM > To: Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > Hadriel, > > We seem to be talking past each other. I interpreted your comment as: > a) the signing of the TN - who may be done directly or on behalf of=20 > the holder - may use a non canonical form of TN, > b) supposing in-band, that signing would then be conveyed in some way=20 > yet TBD untouched to the verifier, and > c) the verifier would then have to compute that "canonical form" to event= ually assert authenticity. > > My comment was that I didn't see how the verifier could reasonably do c) = without prior knowledge of the numbering plan of TN, so either the signer a= nd the verifier implicitly share the function according to which you can tr= anslate the non canonical form into a canonical form (eg they are on the sa= me dialing plan) or I don't see how this could work. Say TN=3D+12125551212,= but a) signs 2125551212 how could c) be correct unless the verifier knows = that it's an NANP number for which adding +1 upfront is enough to make it a= full E.164 number? > > What am I missing here? > > I definitely don't want to force anyone doing anything with the format of= their CLI, I was merely observing that, with the same examples, if a) proc= eeds with 2125551212 and c) is not in the NANP number or doesn't know it's = an NANP number, then I didn't see how it could determine what canonicalizat= ion function to apply. > > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Tuesday, June 25, 2013 8:00 AM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >> I understand it may not be the priority here but as a target I think tha= t grand plan could remain in scope, and again, I think the extra flexibilit= y for a signer is quite minimal in most dialing plans and the added complex= ity for the receiver is in my view not worth it. > > We could certainly have an RFC require the signing domain to generate a T= o/From URI of E.164 and 'user=3Dpart' and all, but I don't see how that wou= ld really succeed: > > 1) From a practical matter, legacy operators can't change all their syste= ms to suddenly use a new format; so you'd be forcing them to do the signing= function on their egress SBCs. While I expect that to be a common scenari= o anyway, I don't think we'd want to force people to doing it there, or on = any SBCs for that matter. It should be possible to do the signing anywhere= on any system type, so long as the signing system knows the caller can cla= im the E.164 number. > > 2) Even if the originator/signer does it that way, by the time the termin= ating domain receives the call it will have come through transit providers = who already today change the To/From URIs. > > >> Finally the irony of not providing a full canonical form is that an=20 >> increasing number of user data profiles contains the subscriber=20 >> number in its full E.164 format, so it may actually require *extra=20 >> work* to provide a different format in a CgP-related header. (I'm not=20 >> referring to R-Us which in the world I live in generally have to be=20 >> manipulated as some point to see the light of the CdP party's=20 >> endpoint or they'll just never get there - if this group were to=20 >> address such use cases, the logic may have to be different IMHO) > > Oh you don't have to provide it in a different format - if you provide it= in an E.164 format today you can continue to with STIR, and you can even c= hange from your current local format to using an E.164 format. We just wou= ldn't be relying on everyone changing over, for STIR to work. > > -hadriel > > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 i= nformation that may be protected by law; they should not be distributed, us= ed 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. > > _______________________________________________ > 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 Tue Jun 25 10: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 A616311E8128 for ; Tue, 25 Jun 2013 10:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.500, 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 YmFqNLm9Gz50 for ; Tue, 25 Jun 2013 10:17:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3861111E8114 for ; Tue, 25 Jun 2013 10:17:56 -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 r5PHHrxJ024242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 17:17: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 r5PHHr5p028151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 17:17:53 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PHHqo8027241; Tue, 25 Jun 2013 17:17:52 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 10:17:52 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51C9CF6F.3060907@alum.mit.edu> Date: Tue, 25 Jun 2013 13:17:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@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] Use of UUI for 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: Tue, 25 Jun 2013 17:18:01 -0000 We'd prepend the contents inside the UUI with some random string, to = prevent such confusion. I.e., the first field of the UUI's payload = would be some magic cookie like "3y87grgv" or whatever, similar to the = "z9hG4bK" of Via branches. -hadriel On Jun 25, 2013, at 1:12 PM, Paul Kyzivat wrote: > When UUI is used in SIP, there are other parameters available to = describe the purpose. On the non-sip links there is only the one byte = prefix, which isn't really helpful for anything. And AFAIK there are no = standards for what the rest looks like. >=20 > So there is the possibility of misunderstanding the purpose of a = received UUI. That must also be taken into account. >=20 > Combine that with the lack of universal support for UUI, and maybe it = just isn't something that makes sense to use for stir. >=20 > Thanks, > Paul >=20 > On 6/25/13 1:03 PM, Hadriel Kaplan wrote: >>=20 >> On Jun 25, 2013, at 12:38 PM, Paul Kyzivat = wrote: >>=20 >>> On 6/25/13 2:19 AM, Hadriel Kaplan wrote: >>>=20 >>>> That depends - if it's literally just a PRI link between Charlie = and Dave, we can tunnel the info in an ISUP UUI. There're even ways of = doing that without requiring the PRI Gateway to be truly aware of it nor = need to be upgraded, depending on the vendors involved. If it's a full = SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier = connecting them, we might still be able to tunnel the UUI through. >>>=20 >>> I've seen this mentioned multiple times on this list. >>>=20 >>> Let us not forget that UUI is there for others to use. >>> We have tools.ietf.org/html/draft-ietf-cuss-sip-uui=E2=80=8E that = defines how to use this in SIP, and which can be tunneled in SS7. >>>=20 >>> I guess this doesn't preclude using UUI for stir, but it certainly = compromises it. >>=20 >> Right, it doesn't preclude use of it for STIR, but it does mean the = UUI may already be being used by another element for the given = INVITE/IAM message. But I'm not sure or not if that will present a real = problem in practice. >>=20 >> For a direct PRI link between two SIP carriers/service-providers, = I've been told that's not really a problem - UUI isn't used nor useful = on such links typically. I don't have much real-world experience seeing = what crosses such links, but from what I hear we'd be ok in using UUI = there. But we'd need to ask some experts who know. >>=20 >> For an SS7 carrier, I've been told the main use of UUI is for = Enterprises which communicate amongst their branch offices, using the = UUI between their HQ and branch PBXs across the SS7 carrier. It = sometimes goes across multiple SS7 carriers, but not as much as staying = only within one carrier as a transport between the PRIs of an = Enterprise. Realistically the UUI is not used between participants who = don't know each other in-advance, because UUI is a proprietary blob and = both ends need to use the same PBX vendor/products to understand the = UUI. >>=20 >> If that's the case, I think we might be ok. Because for an = Enterprise communicating to its carrier using PRIs, STIR isn't = necessary/needed when its talking to its own branch offices and using = the UUI. When it communicates to others, it doesn't send a UUI so we're = free to use it. >>=20 >> That's my theory anyway, from what I hear about its use - but as I = said we'd need to ask some people who deal with that stuff on a daily = basis. >>=20 >> -hadriel >>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From chris_wendt@cable.comcast.com Tue Jun 25 10:20: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 1648C21E80BD for ; Tue, 25 Jun 2013 10:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UojNxkY6YFG for ; Tue, 25 Jun 2013 10:20:00 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 379B121E80C3 for ; Tue, 25 Jun 2013 10:20:00 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.56610897; Tue, 25 Jun 2013 13:18:30 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.141]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Tue, 25 Jun 2013 13:19:50 -0400 From: "Wendt, Chris" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCg== Date: Tue, 25 Jun 2013 17:19:49 +0000 Message-ID: <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> In-Reply-To: <51C9CC99.7020007@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "" Cc: "stir@ietf.org" , Brian Rosen , Hadriel Kaplan , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:20:05 -0000 +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: >> If that's truly the case - that we plan to do an in-band first, and when= that's done then an out-of-band one - then I propose we remove the out-of-= band from the charter. We can always re-charter and add new deliverables w= hen we're ready for an out-of-band mechanism; we re-charter all the time in= RAI groups. We might even decide by then that an out-of-band mechanism sh= ould work very differently, or that defining one isn't necessary, or that w= e don't have the right participants in the IETF to do so successfully. >>=20 >> For now, by removing it from the charter, we can focus on one solution a= nd not have to debate about this aspect during the BOF nor WG meetings. I = am very worried that we won't have a successful BOF - where I measure "succ= ess" as reaching consensus to create a Working Group. Lengthy microphone d= ebates kill BOFs, in my experience. (and I recognize you and Russ and other= s have seen far more BOFs than I have, so maybe I've just been to the wrong= ones ;) >=20 >=20 > +1. >=20 > Narrow, clear focus. >=20 > Good. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Tue Jun 25 10:30: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 3C4F421F99D0 for ; Tue, 25 Jun 2013 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 9dH0petyUwFt for ; Tue, 25 Jun 2013 10:30:42 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9995F21F96EB for ; Tue, 25 Jun 2013 10:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=rgNCcRJp5ryz1eneWnV9JRgxHISMX6X2pjtl1xNqwKM=; b=c3qn3FeZsGoGa3Rg+dlVJWftLkXf4uV3dDrhot5q6bwIqud4MbYeXk+xsYGzH11d75TffsYAIz6CZ6su5XHaRCwW8CnZlHZHmQCkp5B8WrsciAKIn9eY1dcpjFrCvY0L1FVt8W34yt6PuieUevcmgDyLuyFbCg+t1WIJ+ezvuRM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:26914 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrX4i-000172-DF; Tue, 25 Jun 2013 13:30:40 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> Date: Tue, 25 Jun 2013 13:30:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7DD10FA5-15D4-456C-968A-84BBB4BDECF7@brianrosen.net> References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:30:47 -0000 If they originate and terminate in the same enterprise, then both know = the dial plan. We might have a few words in the doc that cover this = case which makes an exception for the canonicalization to e.164 as long = as they can canonicalize to something they both understand. Brian On Jun 25, 2013, at 1:15 PM, "Dwight, Timothy M (Tim)" = wrote: > It's not just an issue of what gets displayed. The PBX may have = different policies for internal and external calls. It's not = necessarily the case that every PBX in an Enterprise knows the E.164 = numbers of every other PBX in the Enterprise. That's why they have = private dial plans... >=20 > I won't comment on what works poorly or well, other than to note that = most solutions can be made to fall into either category. >=20 > This may all be moot if it's agreed to exclude calls that originate = and terminate within the same Enterprise, from this activity. >=20 > Tim >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: Tuesday, June 25, 2013 12:05 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 > On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: >> What about the private dial plan / sip trunking scenarios? In that = case it may be desired to deliver the FROM header in "non-canonical" = format, so that the recipient can know that this was an "internal" call. >=20 > I have never understood this argument. >=20 > If the call is "internal" (because the caller and callee are in the = same enterprise, regardless of whether the call transited a public hop), = then the recipient should be able to recognize that the From, in E.164 = format, is an internal number. If it wants, the receiving device can = apply the inverse of the dial plan to the number to produce an internal = dial string that represents the caller, and display that as the caller = id. >=20 > I have experienced behavior such as you describe, that worked poorly, = because individual sites of the enterprise have different dial plans, so = that the "local" number at one site has a different meaning when = displayed as caller id for the callee at a different site. >=20 > If the calling number has no E.164 equivalent, then the = telephone-subscriber syntax used in both TEL and SIP has a phone-context = param that can be used to represent the private number in a globally = unique way. >=20 > Thanks, > Paul >=20 >> tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Henning Schulzrinne >> Sent: Tuesday, June 25, 2013 10:13 AM >> To: philippe.fouquart@orange.com; Hadriel Kaplan >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >> The signed entity would always be a full E.164 number, as the theory = is that both calling and called carrier are able to derive that = canonical format, as they need to do today for SS7 signaling, CNAM and = intercarrier compensation. Thus, the originating carrier would never = sign 212-555-1212, but only +12125551212. >>=20 >> ________________________________________ >> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of=20 >> philippe.fouquart@orange.com [philippe.fouquart@orange.com] >> Sent: Tuesday, June 25, 2013 8:49 AM >> To: Hadriel Kaplan >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >> Hadriel, >>=20 >> We seem to be talking past each other. I interpreted your comment as: >> a) the signing of the TN - who may be done directly or on behalf of=20= >> the holder - may use a non canonical form of TN, >> b) supposing in-band, that signing would then be conveyed in some way=20= >> yet TBD untouched to the verifier, and >> c) the verifier would then have to compute that "canonical form" to = eventually assert authenticity. >>=20 >> My comment was that I didn't see how the verifier could reasonably do = c) without prior knowledge of the numbering plan of TN, so either the = signer and the verifier implicitly share the function according to which = you can translate the non canonical form into a canonical form (eg they = are on the same dialing plan) or I don't see how this could work. Say = TN=3D+12125551212, but a) signs 2125551212 how could c) be correct = unless the verifier knows that it's an NANP number for which adding +1 = upfront is enough to make it a full E.164 number? >>=20 >> What am I missing here? >>=20 >> I definitely don't want to force anyone doing anything with the = format of their CLI, I was merely observing that, with the same = examples, if a) proceeds with 2125551212 and c) is not in the NANP = number or doesn't know it's an NANP number, then I didn't see how it = could determine what canonicalization function to apply. >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >> Sent: Tuesday, June 25, 2013 8:00 AM >> To: FOUQUART Philippe OLNC/OLN >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >>=20 >> On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >>> I understand it may not be the priority here but as a target I think = that grand plan could remain in scope, and again, I think the extra = flexibility for a signer is quite minimal in most dialing plans and the = added complexity for the receiver is in my view not worth it. >>=20 >> We could certainly have an RFC require the signing domain to generate = a To/=46rom URI of E.164 and 'user=3Dpart' and all, but I don't see how = that would really succeed: >>=20 >> 1) =46rom a practical matter, legacy operators can't change all their = systems to suddenly use a new format; so you'd be forcing them to do the = signing function on their egress SBCs. While I expect that to be a = common scenario anyway, I don't think we'd want to force people to doing = it there, or on any SBCs for that matter. It should be possible to do = the signing anywhere on any system type, so long as the signing system = knows the caller can claim the E.164 number. >>=20 >> 2) Even if the originator/signer does it that way, by the time the = terminating domain receives the call it will have come through transit = providers who already today change the To/=46rom URIs. >>=20 >>=20 >>> Finally the irony of not providing a full canonical form is that an=20= >>> increasing number of user data profiles contains the subscriber=20 >>> number in its full E.164 format, so it may actually require *extra=20= >>> work* to provide a different format in a CgP-related header. (I'm = not=20 >>> referring to R-Us which in the world I live in generally have to be=20= >>> manipulated as some point to see the light of the CdP party's=20 >>> endpoint or they'll just never get there - if this group were to=20 >>> address such use cases, the logic may have to be different IMHO) >>=20 >> Oh you don't have to provide it in a different format - if you = provide it in an E.164 format today you can continue to with STIR, and = you can even change from your current local format to using an E.164 = format. We just wouldn't be relying on everyone changing over, for STIR = to work. >>=20 >> -hadriel >>=20 >>=20 >>=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 >> _______________________________________________ >> 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 >=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 hadriel.kaplan@oracle.com Tue Jun 25 10:31: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 068F321F9C58 for ; Tue, 25 Jun 2013 10:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.633, 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 rKGMsqT3M32e for ; Tue, 25 Jun 2013 10:31:46 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9821F9C44 for ; Tue, 25 Jun 2013 10:31:46 -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 r5PHPQGM009715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 17:25:27 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 r5PHVh9k006302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 17:31:44 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 r5PHVhx9006298; Tue, 25 Jun 2013 17:31:43 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 10:31:43 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 25 Jun 2013 13:31:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B9DE92F-CE1E-42C7-A5FC-A477B47B1717@oracle.com> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:31:53 -0000 On Jun 25, 2013, at 8:48 AM, "Rosen, Brian" = wrote: > I get that termination TN has to be able to be canonicalized, because = routing has to work. >=20 > What do we do about From? >=20 > As it is today, can the terminating domain extract a canonical e.164 = from what is actually sent? Yes, I think it's a very safe bet that the terminating domain can figure = out what the E.164 source identity is. My evidence of that is that = terminating carriers use the source info a LOT, on a bunch of systems: = voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, = etc. And of course they ultimately display them as caller-ids on their = subscriber's phones. And the transit carriers can too, because they also use the source = identity: for billing and for source-based routing (which is common for = transits). > Alternatively, is it reasonable for the ingress SBC to rewrite it so = it can be? The SBC already rewrite the =46rom - they convert it into a format the = local operator can understand/use, so that it works in those systems I = mentioned above. The SBCs can determine what the equivalent E.164 number is so that they = can do the verifying, but they couldn't convert the =46rom into a = "compliant" E.164 format, because then it won't work on those systems I = mentioned above. > Or do we rely on P-A-I? Well... whether to use the =46rom or PAI as the source identity is a bit = tricky. PAI is also very commonly used for some of the things we'd want = to have validated caller-ids for, and goes across/between some carriers = too. In other words, some of those systems I mentioned above use the = PAI instead of the From, but I think we'd be ok saying in the RFC to = validate the From, and if the =46rom doesn't match the PAI then leave it = up to local policy to decide what to do. 3GPP will go define what to do = in that circumstance for IMS, for example. -hadriel From br@brianrosen.net Tue Jun 25 10:36: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 62A1E21F9D58 for ; Tue, 25 Jun 2013 10:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.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_52=0.6, RDNS_NONE=0.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 4tPBrbEO1dvM for ; Tue, 25 Jun 2013 10:35:58 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id A02B121F9B8C for ; Tue, 25 Jun 2013 10:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=k6ST9Xv99R9e/cU+dZusV2vIcL4ii/tRVWpDYf0YuBc=; b=JkBJb+7voJwPNPR4AwkZJHQtzoyemeaH/iVVm2XMnxF9PBa7YQTNu6ZGrPgI2pkV7NrrVOeZWpoCVBdjhRBFLzg7ezdn+qaxnnhm8qBITLWnGQDQx2DAGfgMSvULB/ECnNGwcc992qdSu8tiC6tA06k/SHMDuncjDUsKFU4PeWc=; Received: from neustargw.va.neustar.com ([209.173.53.233]:40020 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrX9n-0002mU-EO; Tue, 25 Jun 2013 13:35:55 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> Date: Tue, 25 Jun 2013 13:35:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@alum.mit.edu> <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 17:36:02 -0000 If it works to use UUI, that would be great, but I don't know if UUI = would survive most of the SS7 hops, especially if there is a transit = carrier in the path, which I suspect is pretty common in the cases we = care about. The alternative I proposed was a new database the SIP->SS7 GW wrote and = the SS7->SIP GW searched to restore the identity signature. That would = always work, and we probably could work out reasonable ways to avoid = privacy issues because we would be in a more trusted environment, with a = restricted set of users who we would have good identity for. Brian On Jun 25, 2013, at 1:17 PM, Hadriel Kaplan = wrote: >=20 > We'd prepend the contents inside the UUI with some random string, to = prevent such confusion. I.e., the first field of the UUI's payload = would be some magic cookie like "3y87grgv" or whatever, similar to the = "z9hG4bK" of Via branches. >=20 > -hadriel >=20 >=20 > On Jun 25, 2013, at 1:12 PM, Paul Kyzivat = wrote: >=20 >> When UUI is used in SIP, there are other parameters available to = describe the purpose. On the non-sip links there is only the one byte = prefix, which isn't really helpful for anything. And AFAIK there are no = standards for what the rest looks like. >>=20 >> So there is the possibility of misunderstanding the purpose of a = received UUI. That must also be taken into account. >>=20 >> Combine that with the lack of universal support for UUI, and maybe it = just isn't something that makes sense to use for stir. >>=20 >> Thanks, >> Paul >>=20 >> On 6/25/13 1:03 PM, Hadriel Kaplan wrote: >>>=20 >>> On Jun 25, 2013, at 12:38 PM, Paul Kyzivat = wrote: >>>=20 >>>> On 6/25/13 2:19 AM, Hadriel Kaplan wrote: >>>>=20 >>>>> That depends - if it's literally just a PRI link between Charlie = and Dave, we can tunnel the info in an ISUP UUI. There're even ways of = doing that without requiring the PRI Gateway to be truly aware of it nor = need to be upgraded, depending on the vendors involved. If it's a full = SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier = connecting them, we might still be able to tunnel the UUI through. >>>>=20 >>>> I've seen this mentioned multiple times on this list. >>>>=20 >>>> Let us not forget that UUI is there for others to use. >>>> We have tools.ietf.org/html/draft-ietf-cuss-sip-uui=E2=80=8E that = defines how to use this in SIP, and which can be tunneled in SS7. >>>>=20 >>>> I guess this doesn't preclude using UUI for stir, but it certainly = compromises it. >>>=20 >>> Right, it doesn't preclude use of it for STIR, but it does mean the = UUI may already be being used by another element for the given = INVITE/IAM message. But I'm not sure or not if that will present a real = problem in practice. >>>=20 >>> For a direct PRI link between two SIP carriers/service-providers, = I've been told that's not really a problem - UUI isn't used nor useful = on such links typically. I don't have much real-world experience seeing = what crosses such links, but from what I hear we'd be ok in using UUI = there. But we'd need to ask some experts who know. >>>=20 >>> For an SS7 carrier, I've been told the main use of UUI is for = Enterprises which communicate amongst their branch offices, using the = UUI between their HQ and branch PBXs across the SS7 carrier. It = sometimes goes across multiple SS7 carriers, but not as much as staying = only within one carrier as a transport between the PRIs of an = Enterprise. Realistically the UUI is not used between participants who = don't know each other in-advance, because UUI is a proprietary blob and = both ends need to use the same PBX vendor/products to understand the = UUI. >>>=20 >>> If that's the case, I think we might be ok. Because for an = Enterprise communicating to its carrier using PRIs, STIR isn't = necessary/needed when its talking to its own branch offices and using = the UUI. When it communicates to others, it doesn't send a UUI so we're = free to use it. >>>=20 >>> That's my theory anyway, from what I hear about its use - but as I = said we'd need to ask some people who deal with that stuff on a daily = basis. >>>=20 >>> -hadriel >>>=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 brian.rosen@neustar.biz Tue Jun 25 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 EB6AF21F9E43 for ; Tue, 25 Jun 2013 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 E5bMvOK58MN9 for ; Tue, 25 Jun 2013 10:38:10 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7621F9E55 for ; Tue, 25 Jun 2013 10:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372182069; x=1687538549; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=bKoMWEfhQU mhLJAtVUZ0ZufImZYOZ1UPBZjQMCDWrqs=; b=o36JlTC79Sg0Z32tiWXwA5zAQo jBZQlaniCCdcIu1is8CQlWeetqhjRtBr7SYGCfErW9XURgIYM0m/QV8CqqAQ== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25662540; Tue, 25 Jun 2013 13:41:08 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 13:38:04 -0400 From: "Rosen, Brian" To: Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObb1Irceg+8rbrkSvrqRLwReGiJk+6X2AgAAoCYCAASNrAIAAgvYAgASasoCAAOd4AIAAcf2AgABPOoCAAAHIgA== Date: Tue, 25 Jun 2013 17:38:04 +0000 Message-ID: <6AA953CD-B27E-4518-9DC8-5DB148408941@neustar.biz> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> <8B9DE92F-CE1E-42C7-A5FC-A477B47B1717@oracle.com> In-Reply-To: <8B9DE92F-CE1E-42C7-A5FC-A477B47B1717@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ydIqqlI0xQUx1gED5GdaWA== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.fouquart@orange.com" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:38:14 -0000 Good. =20 I think your suggestion on how to handle PAI is fine. We could have some w= ay to mark the identity header with what was signed if we needed to carry t= hat. Brian On Jun 25, 2013, at 1:31 PM, Hadriel Kaplan wro= te: >=20 > On Jun 25, 2013, at 8:48 AM, "Rosen, Brian" wro= te: >=20 >> I get that termination TN has to be able to be canonicalized, because ro= uting has to work. >>=20 >> What do we do about From? >>=20 >> As it is today, can the terminating domain extract a canonical e.164 fro= m what is actually sent? >=20 > Yes, I think it's a very safe bet that the terminating domain can figure = out what the E.164 source identity is. My evidence of that is that termina= ting carriers use the source info a LOT, on a bunch of systems: voicemail s= ervers, IVRs, CNAM servers, conf bridges, billing systems, etc. And of cou= rse they ultimately display them as caller-ids on their subscriber's phones= . >=20 > And the transit carriers can too, because they also use the source identi= ty: for billing and for source-based routing (which is common for transits)= . >=20 >=20 >> Alternatively, is it reasonable for the ingress SBC to rewrite it so it = can be? >=20 > The SBC already rewrite the From - they convert it into a format the loca= l operator can understand/use, so that it works in those systems I mentione= d above. > The SBCs can determine what the equivalent E.164 number is so that they c= an do the verifying, but they couldn't convert the From into a "compliant" = E.164 format, because then it won't work on those systems I mentioned above= . >=20 >=20 >> Or do we rely on P-A-I? >=20 > Well... whether to use the From or PAI as the source identity is a bit tr= icky. PAI is also very commonly used for some of the things we'd want to h= ave validated caller-ids for, and goes across/between some carriers too. I= n other words, some of those systems I mentioned above use the PAI instead = of the From, but I think we'd be ok saying in the RFC to validate the From,= and if the From doesn't match the PAI then leave it up to local policy to = decide what to do. 3GPP will go define what to do in that circumstance for= IMS, for example. >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Tue Jun 25 10:50: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 1474921E80AD for ; Tue, 25 Jun 2013 10:50: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 szblsSGnPESv for ; Tue, 25 Jun 2013 10:49:59 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id F16B021E8099 for ; Tue, 25 Jun 2013 10:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372182768; x=1687542376; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=xwgmI+bp7e d398ZfS9EoPvu2WSsZVkuGOsA60sSsvio=; b=okl3xxSgIQILKmIT2zgNIjQjOy ZHvQaHH4XXrjdSuURv3i8c9CB8XSUObsrEzCQFIbCGP/U+XuWajy78r+VXAA== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25663441; Tue, 25 Jun 2013 13:52:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 13:49:44 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAI98gIAAArwAgAAJJQCAAMiFgIAAYW+AgAA/UID//53AAA== Date: Tue, 25 Jun 2013 17:49:44 +0000 Message-ID: In-Reply-To: <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: qapO2mUoQHHvp6b/ZEOPwg== Content-Type: text/plain; charset="us-ascii" Content-ID: <9FCBC8F48B5C894D9BB5D643719017CA@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 17:50:03 -0000 Sure, I don't think we need to do these things at the same time. The way the current draft charter is structured, the out-of-band solution is last because we understand it least, and the in-band is more low hanging fruit. It may make sense to structure the charter in such a way that these deliverables aren't immediately listed in the milestones. However, I do think we need to do these things in the same place, as the potential for overlap and reuse makes me reluctant to decouple this entirely. The real-world problems here of vishing, robocalling and so on are not going to be solved by an in-band (that is, for e2e SIP calls) solution alone. If we design the in-band without consideration for what the out-of-band solution might look like, this could take us in the wrong direction. The primary thing we need to be mindful of is the applicability, and where we anticipate the hand-off will be from the in-band to the out-of-band. For that reason I still think we should have discussion of the out-of-band in the charter text, though it should remain at a high level. Jon Peterson Neustar, Inc. On 6/25/13 9:41 AM, "Hadriel Kaplan" wrote: > >On Jun 25, 2013, at 8:54 AM, Brian Rosen wrote: > >> We're all in agreement that we will complete the in band solution >>before we complete the out of band solution so it should be reasonable >>for chairs to manage the WG time effectively. > >If that's truly the case - that we plan to do an in-band first, and when >that's done then an out-of-band one - then I propose we remove the >out-of-band from the charter. We can always re-charter and add new >deliverables when we're ready for an out-of-band mechanism; we re-charter >all the time in RAI groups. We might even decide by then that an >out-of-band mechanism should work very differently, or that defining one >isn't necessary, or that we don't have the right participants in the IETF >to do so successfully. > >For now, by removing it from the charter, we can focus on one solution >and not have to debate about this aspect during the BOF nor WG meetings. >I am very worried that we won't have a successful BOF - where I measure >"success" as reaching consensus to create a Working Group. Lengthy >microphone debates kill BOFs, in my experience. (and I recognize you and >Russ and others have seen far more BOFs than I have, so maybe I've just >been to the wrong ones ;) > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Tue Jun 25 11:06: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 1B5B411E8122 for ; Tue, 25 Jun 2013 11:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 PEpeBgn1CK9V for ; Tue, 25 Jun 2013 11:06:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC7CF21F9C68 for ; Tue, 25 Jun 2013 11:06:51 -0700 (PDT) Received: from [192.168.5.202] (ip-64-134-230-63.public.wayport.net [64.134.230.63]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5PI6cHp030261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 11:06:42 -0700 Message-ID: <51C9DC2A.2080802@dcrocker.net> Date: Tue, 25 Jun 2013 11:06:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Jun 2013 11:06:42 -0700 (PDT) Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band 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, 25 Jun 2013 18:06:57 -0000 On 6/25/2013 10:49 AM, Peterson, Jon wrote: > The primary thing we need to be mindful of is the > applicability, and where we anticipate the hand-off will be from the > in-band to the out-of-band. For that reason I still think we should have > discussion of the out-of-band in the charter text, though it should remain > at a high level. 1. By the reference to hand-offs, you are implying some specific scenarios. Please offer some diagrams that show the architectural relationships between in-band and out-of-band that you expect the work to cover. 2. A charter specifies work to be done. It's not clear how the inclusion of "high-level" discussion about out-of-band is helpful in terms of deliverables, since it won't be the work to be done. The kind of "high-level" reference you suggest never provides meaningful engineering guidance. Mindfulness is wonderful for meditation and dieting, but its utility for standards processes is entirely ambiguous. It's the form without the substance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From andrew.hutton@siemens-enterprise.com Tue Jun 25 11:11: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 D4AB621F9AE3 for ; Tue, 25 Jun 2013 11:11: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 x-emhnIOnbYj for ; Tue, 25 Jun 2013 11:11:15 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5211E8128 for ; Tue, 25 Jun 2013 11:11:15 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9BCB21EB84E5; Tue, 25 Jun 2013 20:11:12 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 20:11:12 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , Brian Rosen Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHOcaM3dZgY5CQoREOGlD3Jy4A7g5lGgNWAgAA4NNA= Date: Tue, 25 Jun 2013 18:11:10 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D8C88@MCHP04MSX.global-ad.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> In-Reply-To: <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 18:11:20 -0000 +1. I was also thinking that these two proposed solutions are so different they= should not be covered by the same WG and if we can agree to do one after t= he other then even better. Also agree there is much more chance of a successful BOF if we can focus on= the in-band solution and not have to debate both. Andy > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: 25 June 2013 17:41 > To: Brian Rosen > Cc: stir@ietf.org; dcrocker@bbiw.net; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band >=20 >=20 > On Jun 25, 2013, at 8:54 AM, Brian Rosen wrote: >=20 > > We're all in agreement that we will complete the in band solution > before we complete the out of band solution so it should be reasonable > for chairs to manage the WG time effectively. >=20 > If that's truly the case - that we plan to do an in-band first, and > when that's done then an out-of-band one - then I propose we remove the > out-of-band from the charter. We can always re-charter and add new > deliverables when we're ready for an out-of-band mechanism; we re- > charter all the time in RAI groups. We might even decide by then that > an out-of-band mechanism should work very differently, or that defining > one isn't necessary, or that we don't have the right participants in > the IETF to do so successfully. >=20 > For now, by removing it from the charter, we can focus on one solution > and not have to debate about this aspect during the BOF nor WG > meetings. I am very worried that we won't have a successful BOF - > where I measure "success" as reaching consensus to create a Working > Group. Lengthy microphone debates kill BOFs, in my experience. (and I > recognize you and Russ and others have seen far more BOFs than I have, > so maybe I've just been to the wrong ones ;) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From andrew.hutton@siemens-enterprise.com Tue Jun 25 11:24: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 3D8A221E80DE for ; Tue, 25 Jun 2013 11:24:53 -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 HxZNoyn3iwZB for ; Tue, 25 Jun 2013 11:24:24 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 243BC21F99D0 for ; Tue, 25 Jun 2013 11:24:00 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F266F23F0506; Tue, 25 Jun 2013 20:23:40 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 20:23:40 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [stir] Use of UUI for stir Thread-Index: AQHOccXnZCL9Iczff0qru06LDSwWkZlGvEzQ Date: Tue, 25 Jun 2013 18:23:39 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D8D07@MCHP04MSX.global-ad.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 18:24:53 -0000 PiBPTjogMjUgSnVuZSAyMDEzIDE4OjAzIEhhZHJpZWwgS2FwbGFuIFdyb3RlOg0KPiBUbzogUGF1 bCBLeXppdmF0DQo+IA0KPiBGb3IgYW4gU1M3IGNhcnJpZXIsIEkndmUgYmVlbiB0b2xkIHRoZSBt YWluIHVzZSBvZiBVVUkgaXMgZm9yDQo+IEVudGVycHJpc2VzIHdoaWNoIGNvbW11bmljYXRlIGFt b25nc3QgdGhlaXIgYnJhbmNoIG9mZmljZXMsIHVzaW5nIHRoZQ0KPiBVVUkgYmV0d2VlbiB0aGVp ciBIUSBhbmQgYnJhbmNoIFBCWHMgYWNyb3NzIHRoZSBTUzcgY2Fycmllci4gIEl0DQo+IHNvbWV0 aW1lcyBnb2VzIGFjcm9zcyBtdWx0aXBsZSBTUzcgY2FycmllcnMsIGJ1dCBub3QgYXMgbXVjaCBh cyBzdGF5aW5nDQo+IG9ubHkgd2l0aGluIG9uZSBjYXJyaWVyIGFzIGEgdHJhbnNwb3J0IGJldHdl ZW4gdGhlIFBSSXMgb2YgYW4NCj4gRW50ZXJwcmlzZS4gIFJlYWxpc3RpY2FsbHkgdGhlIFVVSSBp cyBub3QgdXNlZCBiZXR3ZWVuIHBhcnRpY2lwYW50cyB3aG8NCj4gZG9uJ3Qga25vdyBlYWNoIG90 aGVyIGluLWFkdmFuY2UsIGJlY2F1c2UgVVVJIGlzIGEgcHJvcHJpZXRhcnkgYmxvYiBhbmQNCj4g Ym90aCBlbmRzIG5lZWQgdG8gdXNlIHRoZSBzYW1lIFBCWCB2ZW5kb3IvcHJvZHVjdHMgdG8gdW5k ZXJzdGFuZCB0aGUNCj4gVVVJLg0KPiANCj4gSWYgdGhhdCdzIHRoZSBjYXNlLCBJIHRoaW5rIHdl IG1pZ2h0IGJlIG9rLiAgQmVjYXVzZSBmb3IgYW4gRW50ZXJwcmlzZQ0KPiBjb21tdW5pY2F0aW5n IHRvIGl0cyBjYXJyaWVyIHVzaW5nIFBSSXMsIFNUSVIgaXNuJ3QgbmVjZXNzYXJ5L25lZWRlZA0K PiB3aGVuIGl0cyB0YWxraW5nIHRvIGl0cyBvd24gYnJhbmNoIG9mZmljZXMgYW5kIHVzaW5nIHRo ZSBVVUkuICBXaGVuIGl0DQo+IGNvbW11bmljYXRlcyB0byBvdGhlcnMsIGl0IGRvZXNuJ3Qgc2Vu ZCBhIFVVSSBzbyB3ZSdyZSBmcmVlIHRvIHVzZSBpdC4NCj4gDQo+IFRoYXQncyBteSB0aGVvcnkg YW55d2F5LCBmcm9tIHdoYXQgSSBoZWFyIGFib3V0IGl0cyB1c2UgLSBidXQgYXMgSSBzYWlkDQo+ IHdlJ2QgbmVlZCB0byBhc2sgc29tZSBwZW9wbGUgd2hvIGRlYWwgd2l0aCB0aGF0IHN0dWZmIG9u IGEgZGFpbHkgYmFzaXMuDQoNCkkgdGhpbmsgdGhpcyB0aGVvcnkgaXMgdmVyeSBkdWJpb3VzIGlm IGFuIGVudGVycHJpc2UgaXMgdXNpbmcgUFJJIHRvIGEgY2FycmllciB0byB0YWxrIHRvIGl0cyBv d24gYnJhbmNoZXMgd2h5IHdvdWxkIFNUSVIgbm90IGJlIG5lZWRlZD8NCg0KPiANCj4gLWhhZHJp ZWwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHN0aXIgbWFpbGluZyBsaXN0DQo+IHN0aXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo= From Henning.Schulzrinne@fcc.gov Tue Jun 25 11:34: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 0B2A011E8127 for ; Tue, 25 Jun 2013 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 TBu5tTSgg+ne for ; Tue, 25 Jun 2013 11:34: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 0C16311E8126 for ; Tue, 25 Jun 2013 11:34:08 -0700 (PDT) Message-ID: X-CheckPoint: {51C9E29F-10070-D2C987A5-FFFF} From: Henning Schulzrinne To: "Dwight, Timothy M (Tim)" , "philippe.fouquart@orange.com" , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMwgAALLg2AAAieAIAAGkmx Date: Tue, 25 Jun 2013 18:34:07 +0000 References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> , <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30127E3E0A6@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3E0A6@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: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 18:34:14 -0000 I don't think number spoofing within enterprise networks or within a single= carrier network is a major problem at the moment, so I'm less worried abou= t supporting that case if it requires major contortions.=0A= =0A= I'm a bit worried about having too many identifiers in the same message - w= e want to make sure that the number presented to the user, via caller-ID, c= an be trusted, rather than some other string that the user cannot see and m= ay well differ. While MIM attacks are not a major concern, if you can essen= tially slap a signed block into just about any signaling message, and the c= allerID is interpreted as signed even though the signed block refers to som= e completely different number, this seems like a recipe for mischief.=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: Tuesday, June 25, 2013 1:02 PM=0A= To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan=0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= So you're proposing that SIP trunking services would be exempted from these= requirements? That's one solution I suppose. I'm not opposed.=0A= =0A= You may have more experience that me with SIP trunking services, but in my = limited experience the PBX often needs to know (or at least, will behave di= fferently if it knows) that the call was from an on-net user.=0A= =0A= tim=0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Tuesday, June 25, 2013 11:29 AM=0A= To: Dwight, Timothy M (Tim); philippe.fouquart@orange.com; Hadriel Kaplan= =0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= Traffic that stays within a private network is probably not a major concern= , at least for the "provider-validates" scenario.=0A= My understanding is that in order to deliver usable caller ID to SIP phones= , SIP trunking providers normalize phone numbers except maybe for in-house = extensions.=0A= =0A= ________________________________________=0A= From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]=0A= Sent: Tuesday, June 25, 2013 11:48 AM=0A= To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan=0A= Cc: Rosen, Brian; stir@ietf.org=0A= Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= What about the private dial plan / sip trunking scenarios? In that case it= may be desired to deliver the FROM header in "non-canonical" format, so th= at the recipient can know that this was an "internal" call.=0A= =0A= tim=0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From jon.peterson@neustar.biz Tue Jun 25 11:50: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 DEB1C21F9A0B for ; Tue, 25 Jun 2013 11:50:49 -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 yCDqXn5wzdgQ for ; Tue, 25 Jun 2013 11:50:45 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9723021F9330 for ; Tue, 25 Jun 2013 11:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372186133; x=1687545803; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=uOWdrtqVHs 2jdGTqxANezKhLNSrFdJf6fbk47gh1jyM=; b=fGXBo8zD5hKTpe6FWP1ctpt9wW cDPsLvPzpEQI0QVCHD51cKKqNyXW0X2jkQ+3auahQZG86BH8TEF9S1zQstDQ== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19969984; Tue, 25 Jun 2013 14:48:25 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 14:47:35 -0400 From: "Peterson, Jon" To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" , "philippe.fouquart@orange.com" , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnbsMmZQTrk9EapAINY/F31vZk+4muAgAAHWYCAACgJgIABI2sAgACC9gCABJqygIAA53gAgABygoCAACfSAIAACiiAgAALLgCAAAl+AIAAGYGA//+OZwA= Date: Tue, 25 Jun 2013 18:47:34 +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.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wi/J6H+gUTwbldnlEJ/8og== Content-Type: text/plain; charset="us-ascii" Content-ID: <3CB81E2EB2CD064CAA5F5EDFD8678C02@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 18:50:52 -0000 This has also been my historical concern about asserting identity for some new header field. When an INVITE lands at a SIP device, what if anything do we expect the standard header field value would be that gets displayed to the user as the identity of the caller? The path we went down with RFC3325 (and many subsequent specifications in 3GPP and elsewhere, to say nothing of proprietary measures) increasingly proliferated the identities carried within a request, some of which were never intended to be rendered to end users - certainly per the trust domain definition followed by RFC3325, it would rarely be standard behavior to deliver a PAI header to an end-user device. Back when we were working on RFC4474, the prevailing argument was that the baseline behavior of SIP devices would be to render the From header field, and that's why we focused on it. This thread has amply illustrated that there's no free lunch here in terms of implementing secure identity: either the way service providers handle identifiers, or the way-end user devices render identifiers, or both, will have to change. The discussion here has to be one about which are the least painful and surprising changes, and about where identity information should be carried to reduce the security vulnerability to legacy systems. Jon Peterson Neustar, Inc. On 6/25/13 11:34 AM, "Henning Schulzrinne" wrote: >I don't think number spoofing within enterprise networks or within a >single carrier network is a major problem at the moment, so I'm less >worried about supporting that case if it requires major contortions. > >I'm a bit worried about having too many identifiers in the same message - >we want to make sure that the number presented to the user, via >caller-ID, can be trusted, rather than some other string that the user >cannot see and may well differ. While MIM attacks are not a major >concern, if you can essentially slap a signed block into just about any >signaling message, and the callerID is interpreted as signed even though >the signed block refers to some completely different number, this seems >like a recipe for mischief. > >________________________________________ >From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, >Timothy M (Tim) [timothy.dwight@verizon.com] >Sent: Tuesday, June 25, 2013 1:02 PM >To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan >Cc: Rosen, Brian; stir@ietf.org >Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > >So you're proposing that SIP trunking services would be exempted from >these requirements? That's one solution I suppose. I'm not opposed. > >You may have more experience that me with SIP trunking services, but in >my limited experience the PBX often needs to know (or at least, will >behave differently if it knows) that the call was from an on-net user. > >tim > >-----Original Message----- >From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >Sent: Tuesday, June 25, 2013 11:29 AM >To: Dwight, Timothy M (Tim); philippe.fouquart@orange.com; Hadriel Kaplan >Cc: Rosen, Brian; stir@ietf.org >Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) > >Traffic that stays within a private network is probably not a major >concern, at least for the "provider-validates" scenario. >My understanding is that in order to deliver usable caller ID to SIP >phones, SIP trunking providers normalize phone numbers except maybe for >in-house extensions. > >________________________________________ >From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] >Sent: Tuesday, June 25, 2013 11:48 AM >To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan >Cc: Rosen, Brian; stir@ietf.org >Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) > >What about the private dial plan / sip trunking scenarios? In that case >it may be desired to deliver the FROM header in "non-canonical" format, >so that the recipient can know that this was an "internal" call. > >tim >_______________________________________________ >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 Jun 25 12:06: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 ECA3511E8135 for ; Tue, 25 Jun 2013 12:06:08 -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 7Nsntcl40lA5 for ; Tue, 25 Jun 2013 12:06:05 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A757F21F9AA9 for ; Tue, 25 Jun 2013 12:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372187022; x=1687545803; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=n+443UYyLF 7sAAnEYkSgw0DGPzG9QC+f3tnElYvdc+Q=; b=l9fBz2xwDpjV5w4J5Av2uM9dCf vjsKrE2ELriq88atLh/Y8Rvs2Fuj0kT418u3+h94pVw89FcG1rA4CHGXPfcw== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19970909; Tue, 25 Jun 2013 15:03:41 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 15:05:15 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeiPo9mlqJ3kmapUg6mjJxlJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAI98gIAAArwAgAAJJQCAAMiFgIAAYW+AgAA/UID//53AAIAAehIA//+bCoA= Date: Tue, 25 Jun 2013 19:05:15 +0000 Message-ID: In-Reply-To: <51C9DC2A.2080802@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: mh5TE9CyYQ5FNSQgwo26rQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <5DAF3D467FEAE2468842E58BFBC60FFE@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 19:06:09 -0000 >1. By the reference to hand-offs, you are implying some specific >scenarios. Please offer some diagrams that show the architectural >relationships between in-band and out-of-band that you expect the work >to cover. I did offer a more-than-implicit scenario: if I may paraphrase, it was "in-band assumes e2e SIP" and "not all calls are e2e SIP." This seems like a pretty good reason to be mindful of something other than just in-band. There are already some diagrams in the secure-origins-ps draft that show the difference between these call types. It's just a start, but, well, we're just starting work here. >2. A charter specifies work to be done. It's not clear how the >inclusion of "high-level" discussion about out-of-band is helpful in >terms of deliverables, since it won't be the work to be done. It is helpful for the reason you called a "reference to hand-offs" above. Charters scope work to be done and work not to be done. Identifying modular pieces is helpful. And the idea of including it would be "this isn't the first thing we're going to do, but we're going to do it later." This is not uncommon in IETF charters. >The kind of "high-level" reference you suggest never provides meaningful >engineering guidance. Mindfulness is wonderful for meditation and >dieting, but its utility for standards processes is entirely ambiguous. Charters are high level, and whether or not they provide meaningful engineering guidance is a subject of ongoing controversy. For years I've been a fan of requiring a "boxes and arrows" document that would be more detailed than a charter. We did supply some input drafts that try to take this down at least one level lower. >=20 > It's the form without the substance. Funny, I get the same feeling sometimes. Jon Peterson Neustar, Inc. >d/ > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From michael.hammer@yaanatech.com Tue Jun 25 12:10: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 A6BF721F9A3C for ; Tue, 25 Jun 2013 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 616ED9zqqvEn for ; Tue, 25 Jun 2013 12:10: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 7C8E621F9A3A for ; Tue, 25 Jun 2013 12:10:46 -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, 25 Jun 2013 12:10:43 -0700 From: Michael Hammer To: "timothy.dwight@verizon.com" , "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/g Date: Tue, 25 Jun 2013 19:10:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0245_01CE719D.03618550" MIME-Version: 1.0 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 19:10:50 -0000 ------=_NextPart_000_0245_01CE719D.03618550 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think your last statement is the gist of this issue. Is routing and authentication within a private network in scope for this group. I think not. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dwight, Timothy M (Tim) Sent: Tuesday, June 25, 2013 10:16 AM To: Paul Kyzivat; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) It's not just an issue of what gets displayed. The PBX may have different policies for internal and external calls. It's not necessarily the case that every PBX in an Enterprise knows the E.164 numbers of every other PBX in the Enterprise. That's why they have private dial plans... I won't comment on what works poorly or well, other than to note that most solutions can be made to fall into either category. This may all be moot if it's agreed to exclude calls that originate and terminate within the same Enterprise, from this activity. Tim -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, June 25, 2013 12:05 PM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: > What about the private dial plan / sip trunking scenarios? In that case it may be desired to deliver the FROM header in "non-canonical" format, so that the recipient can know that this was an "internal" call. I have never understood this argument. If the call is "internal" (because the caller and callee are in the same enterprise, regardless of whether the call transited a public hop), then the recipient should be able to recognize that the From, in E.164 format, is an internal number. If it wants, the receiving device can apply the inverse of the dial plan to the number to produce an internal dial string that represents the caller, and display that as the caller id. I have experienced behavior such as you describe, that worked poorly, because individual sites of the enterprise have different dial plans, so that the "local" number at one site has a different meaning when displayed as caller id for the callee at a different site. If the calling number has no E.164 equivalent, then the telephone-subscriber syntax used in both TEL and SIP has a phone-context param that can be used to represent the private number in a globally unique way. Thanks, Paul > tim > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Tuesday, June 25, 2013 10:13 AM > To: philippe.fouquart@orange.com; Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > The signed entity would always be a full E.164 number, as the theory is that both calling and called carrier are able to derive that canonical format, as they need to do today for SS7 signaling, CNAM and intercarrier compensation. Thus, the originating carrier would never sign 212-555-1212, but only +12125551212. > > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of > philippe.fouquart@orange.com [philippe.fouquart@orange.com] > Sent: Tuesday, June 25, 2013 8:49 AM > To: Hadriel Kaplan > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > Hadriel, > > We seem to be talking past each other. I interpreted your comment as: > a) the signing of the TN - who may be done directly or on behalf of > the holder - may use a non canonical form of TN, > b) supposing in-band, that signing would then be conveyed in some way > yet TBD untouched to the verifier, and > c) the verifier would then have to compute that "canonical form" to eventually assert authenticity. > > My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=+12125551212, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number? > > What am I missing here? > > I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply. > > Philippe Fouquart > Orange Labs Networks > +33 (0) 1 45 29 58 13 > > > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Tuesday, June 25, 2013 8:00 AM > To: FOUQUART Philippe OLNC/OLN > Cc: Rosen, Brian; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >> I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexity for the receiver is in my view not worth it. > > We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed: > > 1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs. While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on any SBCs for that matter. It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number. > > 2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs. > > >> Finally the irony of not providing a full canonical form is that an >> increasing number of user data profiles contains the subscriber >> number in its full E.164 format, so it may actually require *extra >> work* to provide a different format in a CgP-related header. (I'm not >> referring to R-Us which in the world I live in generally have to be >> manipulated as some point to see the light of the CdP party's >> endpoint or they'll just never get there - if this group were to >> address such use cases, the logic may have to be different IMHO) > > Oh you don't have to provide it in a different format - if you provide it in an E.164 format today you can continue to with STIR, and you can even change from your current local format to using an E.164 format. We just wouldn't be relying on everyone changing over, for STIR to work. > > -hadriel > > > > ______________________________________________________________________ > ___________________________________________________ > > 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. > > _______________________________________________ > 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_0245_01CE719D.03618550 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NTE5MTA0MlowIwYJKoZIhvcNAQkEMRYEFPXnQXPbLk/kBEmhCjPCDHc6E1yOMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAT2qlfoY1nnPE6jCIxBCwBGVaLUMpUfZB8w0yFSNK DS/iGQSLRFrwBk85lP1AG2+9OhZNMLnWhCAuRJ7pVAPa72o6KzSyh3s+1K+PCPDqOQq0u7L/I5D4 hzUndOwadfSZgkpWKPG02sdRh+hqZHlxWNfqerRatlKabBsJU4ll28X1NOtSqS66edT4+S/njG6v QIAJc2YOpzf1fPKKEoXjbERwE6w9vHSEY9XCewnfeyVkLOk7hiFrftFL4W8Lix8BrC61Tci3uQOJ V6ZFcNgIG/00OnrQ0v2k3yQqOr2NFHFXG7mJgJfVvBl2kgJxzGFSKQlyGVN0NzbKM05QqoYHZgAA AAAAAA== ------=_NextPart_000_0245_01CE719D.03618550-- From hadriel.kaplan@oracle.com Tue Jun 25 12:11: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 A988321E80DC for ; Tue, 25 Jun 2013 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 acb9fYM3mEo1 for ; Tue, 25 Jun 2013 12:11:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 123E521F9A35 for ; Tue, 25 Jun 2013 12:11:01 -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 r5PJ4eDK005691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 19:04:41 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 r5PJAvDh004949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 19:10:58 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PJAvSL026146; Tue, 25 Jun 2013 19:10:57 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 12:10:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115D8D07@MCHP04MSX.global-ad.net> Date: Tue, 25 Jun 2013 15:10:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55CCD4B9-9C35-445F-ADAF-7903FE8E7C09@oracle.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF115D8D07@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 19:11:09 -0000 On Jun 25, 2013, at 2:23 PM, "Hutton, Andrew" = wrote: >> ON: 25 June 2013 18:03 Hadriel Kaplan Wrote: >> To: Paul Kyzivat >>=20 >> If that's the case, I think we might be ok. Because for an = Enterprise >> communicating to its carrier using PRIs, STIR isn't necessary/needed >> when its talking to its own branch offices and using the UUI. When = it >> communicates to others, it doesn't send a UUI so we're free to use = it. >=20 > I think this theory is very dubious if an enterprise is using PRI to a = carrier to talk to its own branches why would STIR not be needed? To be clear: I don't mean if a PBX uses a PRI to talk to its branches it = can't use the same PRI for calling the PSTN - it can, and it can use = STIR for the PSTN-based calls. It just can't use STIR for the = inter-branch calls. And I'm saying that's ok - securing source identity = for inter-branch calls isn't a problem we're trying to solve. And as = far as I know there's not been a problem with spoofed caller-id's for = inter-branch calls in the real world. Has there? -hadriel From hadriel.kaplan@oracle.com Tue Jun 25 12:28: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 64A5F11E814D for ; Tue, 25 Jun 2013 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 sxrnplsim7H8 for ; Tue, 25 Jun 2013 12:28:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B811E8147 for ; Tue, 25 Jun 2013 12:28:39 -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 r5PJMGvO008098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 19:22:17 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 r5PJSXGT025938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 19:28:34 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PJSXOL005895; Tue, 25 Jun 2013 19:28:33 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 12:28: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: <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> Date: Tue, 25 Jun 2013 15:28:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65B90022-D22B-439E-938F-8FE7D9581C16@oracle.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@alum.mit.edu> <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 19:28:46 -0000 On Jun 25, 2013, at 1:35 PM, Brian Rosen wrote: > If it works to use UUI, that would be great, but I don't know if UUI = would survive most of the SS7 hops, especially if there is a transit = carrier in the path, which I suspect is pretty common in the cases we = care about. It won't work in those cases - I had said that earlier on this or = another thread: it might work for direct PRI links, or for a single SS7 = transit carrier, but if there are multiple transits it's doubtful. I'm = not claiming it's going to work across SS7 everywhere in all cases, or = even in most cases for that matter. But I don't think that's a problem we need to solve - not by the time we = actually have a solution that could solve it. Yes there will still be = SS7 in 10 years, but if we've reduced the volume of caller-id spoofing = and the only remaining way to spoof a caller-id is to get your call to = go through multiple SS7 carriers, then I really think we'd be breaking = out the Champagne. > The alternative I proposed was a new database the SIP->SS7 GW wrote = and the SS7->SIP GW searched to restore the identity signature. That = would always work, and we probably could work out reasonable ways to = avoid privacy issues because we would be in a more trusted environment, = with a restricted set of users who we would have good identity for. Sorry I missed that proposal somewhere. Did you send it in an email? = (there have been a lot of emails on this list :) If I get the gist of what you're proposing, effectively it's an = out-of-band mechanism, but just a private one for carriers rather than a = public one? Again, from a purely technical perspective I don't debate we could = define something like that in drafts that pass a Working Group and IETF = Last-Call, IESG review, and get published as RFCs by the RFC Editor.=20 -hadriel From br@brianrosen.net Tue Jun 25 12:30: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 8058C11E814C for ; Tue, 25 Jun 2013 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.287 X-Spam-Level: X-Spam-Status: No, score=-100.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 fx-JfO1WkAQa for ; Tue, 25 Jun 2013 12:30:17 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 590C111E8147 for ; Tue, 25 Jun 2013 12:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=tOrcUVqU3IF9PwoSL01T73z28LsJO37dvj9Cjrowja8=; b=PvAbwl9eCMQXvLIZnGbEdvgghKEZeinMad6hVTFcOyO+0lAgg4ma4QZ1Z0j5LzA04kqmOOSH2rZOdAnKN+Nv6cQahCS04UQIFalFr9iIBba77zlXRHV55ceTtfD9iTtg5WKo2Uae2hZs05EHUSNJMgJP3EHDcVoLXcBtmwz9BtU=; Received: from neustargw.va.neustar.com ([209.173.53.233]:39434 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UrYwR-0004Uu-JM; Tue, 25 Jun 2013 15:30:15 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <65B90022-D22B-439E-938F-8FE7D9581C16@oracle.com> Date: Tue, 25 Jun 2013 15:30:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11865C6B-CD74-49ED-BDB6-AA7E3BECE7C4@brianrosen.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@alum.mit.edu> <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> <65B90022-D22B-439E-938F-8FE7D9581C16@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 19:30:22 -0000 > Sorry I missed that proposal somewhere. Did you send it in an email? = (there have been a lot of emails on this list :) Yeah, I did >=20 > If I get the gist of what you're proposing, effectively it's an = out-of-band mechanism, but just a private one for carriers rather than a = public one? > Again, from a purely technical perspective I don't debate we could = define something like that in drafts that pass a Working Group and IETF = Last-Call, IESG review, and get published as RFCs by the RFC Editor.=20 Meaning not deployed? Why? From andrew.hutton@siemens-enterprise.com Tue Jun 25 13:25: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 8B9D211E815A for ; Tue, 25 Jun 2013 13:25:35 -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 UHAh6WRQ5gcU for ; Tue, 25 Jun 2013 13:25:29 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DB85F11E8152 for ; Tue, 25 Jun 2013 13:24:35 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 264A123F0450; Tue, 25 Jun 2013 22:24:24 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 22:24:23 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan Thread-Topic: [stir] Use of UUI for stir Thread-Index: AQHOccXnZCL9Iczff0qru06LDSwWkZlGvEzQ///uEICAADWegA== Date: Tue, 25 Jun 2013 20:24:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115D9229@MCHP04MSX.global-ad.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF115D8D07@MCHP04MSX.global-ad.net> <55CCD4B9-9C35-445F-ADAF-7903FE8E7C09@oracle.com> In-Reply-To: <55CCD4B9-9C35-445F-ADAF-7903FE8E7C09@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 20:25:39 -0000 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: 25 June 2013 20:11 > To: Hutton, Andrew > Cc: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] Use of UUI for stir >=20 >=20 > On Jun 25, 2013, at 2:23 PM, "Hutton, Andrew" enterprise.com> wrote: >=20 > >> ON: 25 June 2013 18:03 Hadriel Kaplan Wrote: > >> To: Paul Kyzivat > >> > >> If that's the case, I think we might be ok. Because for an > Enterprise > >> communicating to its carrier using PRIs, STIR isn't necessary/needed > >> when its talking to its own branch offices and using the UUI. When > it > >> communicates to others, it doesn't send a UUI so we're free to use > it. > > > > I think this theory is very dubious if an enterprise is using PRI to > a carrier to talk to its own branches why would STIR not be needed? >=20 >=20 > To be clear: I don't mean if a PBX uses a PRI to talk to its branches > it can't use the same PRI for calling the PSTN - it can, and it can use > STIR for the PSTN-based calls. It just can't use STIR for the inter- > branch calls. And I'm saying that's ok - securing source identity for > inter-branch calls isn't a problem we're trying to solve. And as far > as I know there's not been a problem with spoofed caller-id's for > inter-branch calls in the real world. Has there? If you mean that it cannot use STIR for calls within a private numbering pl= an then I am ok with that. Andy >=20 > -hadriel From hadriel.kaplan@oracle.com Tue Jun 25 13:32: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 8586621E809F for ; Tue, 25 Jun 2013 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.017, 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 L46kbr9ubB54 for ; Tue, 25 Jun 2013 13:32:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id EEEDB11E8131 for ; Tue, 25 Jun 2013 13:32:22 -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 r5PKQ1Da006774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 20:26:01 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 r5PKWI7C024727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 20:32:19 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PKWIhW008568; Tue, 25 Jun 2013 20:32:18 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jun 2013 13:32:18 -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: <11865C6B-CD74-49ED-BDB6-AA7E3BECE7C4@brianrosen.net> Date: Tue, 25 Jun 2013 16:32:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C4CE80.40701@dcrocker.net>> <> > <> <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@alum.mit.edu> <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> <65B90022-D22B-439E-938F-8FE7D9581C16@oracle.com> <11865C6B-CD74-49ED-BDB6-AA7E3BECE7C4@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 20:32:29 -0000 On Jun 25, 2013, at 3:30 PM, Brian Rosen wrote: >> If I get the gist of what you're proposing, effectively it's an = out-of-band mechanism, but just a private one for carriers rather than a = public one? >> Again, from a purely technical perspective I don't debate we could = define something like that in drafts that pass a Working Group and IETF = Last-Call, IESG review, and get published as RFCs by the RFC Editor.=20 > Meaning not deployed? Why? Because if you send the call into SS7, without any idea of who/what's = beyond, and can't send something in-band to tell the far-end carrier = why/how it should believe your caller-id, then you'd have to tell some = third-party you really trust instead (ie, EKR's CDS server cloud = thingy). You'd have to believe the far-end carrier would use the same = third-party to verify, even though you don't know who that far-end = carrier is. For that to work, it means there're only one or two such = third-parties for a given country, or even for the planet Earth = (depending on the details of how this thing would work). The only way I'd believe that could really happen is for either (1) = regulatory bodies to choose a third-party for everyone to use, or (2) = enough of the big carriers to choose a common third-party that it = drives/forces everyone else to use the same. I don't debate (1) is = possible, but it's a big deal to get that to happen and the regulatory = effort would be better spent making the legacy carriers move to a = technology that can transport the caller-id info (which does not need to = be SIP, btw - it could be H.323, XMPP, or whatever). Doing that not = only provides the caller-id we need, but also keeps us from giving = regulated monopoly power to a third-party. I would believe in (2) a lot = more, but I don't believe the big carriers want to give even de-facto = monopoly power to a third-party if they can avoid it. It always bites = them in the a$$ in the end. -hadriel From br@brianrosen.net Tue Jun 25 13:38: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 1012A21F8D73 for ; Tue, 25 Jun 2013 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.037 X-Spam-Level: X-Spam-Status: No, score=-100.037 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.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 D79nDkKak1fB for ; Tue, 25 Jun 2013 13:38:20 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id D829C21F8FC4 for ; Tue, 25 Jun 2013 13:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=+DufmUl9L0B5x2mzwvYrqVEzh628qAcNDDRyu8Cjvt0=; b=a8XwJdZY3Gtl2f1nkijnc9DOUt1Rn1c2rJ6nWCJreLAaDzLpMrSUvLh66E/4xQjd1d+tUGo7m4UAFK+c6znKrL3MaHXwWoOOmOyKZ1O/jI5Fs9bqik7joq8vUU4bDTIhSieq2NWdD55FMtmGafJoP7AGaANDtaiPnseN+JYQvZk=; Received: from neustargw.va.neustar.com ([209.173.53.233]:42956 helo=[10.33.193.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Ura0H-00016U-Ng; Tue, 25 Jun 2013 16:38:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Tue, 25 Jun 2013 16:38:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8589FB2E-4634-40D0-AACA-53B3E949FCBA@brianrosen.net> References: <51C4CE80.40701@dcrocker.net>> <> > <> <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> <51C9CF6F.3060907@alum.mit.edu> <8049A14F-1709-468C-9AE4-E551877D181F@oracle.com> <328AF3DF-CFFD-4155-9651-D57C9E968CFC@brianrosen.net> <65B90022-D22B-439E-938F-8FE7D9581C16@oracle.com> <11865C6B-CD74-49ED-BDB6-AA7E3BECE7C4@brianrosen.net> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: stir@ietf.org, Paul Kyzivat Subject: Re: [stir] Use of UUI for 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: Tue, 25 Jun 2013 20:38:25 -0000 Yeah, there has to be one per country with some LoST like thingy for an = international call. I think it would be #2. The $damage is limited because the big guys = will be exiting SS7 sooner rather than later, although I think that's a = decade. Brian On Jun 25, 2013, at 4:32 PM, Hadriel Kaplan = wrote: >=20 > On Jun 25, 2013, at 3:30 PM, Brian Rosen wrote: >=20 >>> If I get the gist of what you're proposing, effectively it's an = out-of-band mechanism, but just a private one for carriers rather than a = public one? >>> Again, from a purely technical perspective I don't debate we could = define something like that in drafts that pass a Working Group and IETF = Last-Call, IESG review, and get published as RFCs by the RFC Editor.=20 >> Meaning not deployed? Why? >=20 > Because if you send the call into SS7, without any idea of who/what's = beyond, and can't send something in-band to tell the far-end carrier = why/how it should believe your caller-id, then you'd have to tell some = third-party you really trust instead (ie, EKR's CDS server cloud = thingy). You'd have to believe the far-end carrier would use the same = third-party to verify, even though you don't know who that far-end = carrier is. For that to work, it means there're only one or two such = third-parties for a given country, or even for the planet Earth = (depending on the details of how this thing would work). >=20 > The only way I'd believe that could really happen is for either (1) = regulatory bodies to choose a third-party for everyone to use, or (2) = enough of the big carriers to choose a common third-party that it = drives/forces everyone else to use the same. I don't debate (1) is = possible, but it's a big deal to get that to happen and the regulatory = effort would be better spent making the legacy carriers move to a = technology that can transport the caller-id info (which does not need to = be SIP, btw - it could be H.323, XMPP, or whatever). Doing that not = only provides the caller-id we need, but also keeps us from giving = regulated monopoly power to a third-party. I would believe in (2) a lot = more, but I don't believe the big carriers want to give even de-facto = monopoly power to a third-party if they can avoid it. It always bites = them in the a$$ in the end. >=20 > -hadriel >=20 From dhc@dcrocker.net Tue Jun 25 22: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 909C821F9F92 for ; Tue, 25 Jun 2013 22:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G17A65DQ6elU for ; Tue, 25 Jun 2013 22:34:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42421F9FD0 for ; Tue, 25 Jun 2013 22:34:42 -0700 (PDT) Received: from [10.58.166.158] (72-254-44-206.client.stsn.net [72.254.44.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5Q5YcGu009211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 22:34:41 -0700 Message-ID: <51CA7D69.9020507@dcrocker.net> Date: Tue, 25 Jun 2013 22:34:33 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 25 Jun 2013 22:34:41 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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, 26 Jun 2013 05:34:47 -0000 On 6/25/2013 12:05 PM, Peterson, Jon wrote: >> 2. A charter specifies work to be done. It's not clear how the >> inclusion of "high-level" discussion about out-of-band is helpful in >> terms of deliverables, since it won't be the work to be done. > > It is helpful for the reason you called a "reference to hand-offs" above. Actually it doesn't. More often it's counter-productive. In a form that generic, it has no technical substance and offers no guidance. Anything could qualify within it. Anything could be excluded. The usual effect of text like that is to distract from doing a clean design. It winds up causing people to instead attempt an awkward hybrid design -- trying to solve both problems -- rather than a clean, focused one. > Charters scope work to be done and work not to be done. A generic statement along the lines of the "be mindful of..." sort that you want to add does neither. > Identifying > modular pieces is helpful. Sure is. But you've just cited that as if it relates to the discussion. Perhaps it does, but it isn't obvious how. > And the idea of including it would be "this > isn't the first thing we're going to do, but we're going to do it later." Charter language along those lines is primarily used to say "ignore these issues now because they are out of scope now". That can, indeed, be helpful for focusing a working group that is easily subject to distraction. Unfortunately, that's not the purpose you have in mind. "Be mindful of" serves exactly the opposite purpose. > This is not uncommon in IETF charters. Not uncommon. Almost never useful. More typically distracting. In the face of problem and solution spaces that have already displayed serious challenges in producing coherent group discussion, that's exactly the danger to worry about with such extraneous text in the charter. If the charter is not disciplined, it's unlikely the working group will be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From oej@edvina.net Wed Jun 26 00: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 7D9B321E80CD for ; Wed, 26 Jun 2013 00:52:11 -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 Aj+xG4QG1h4R for ; Wed, 26 Jun 2013 00:52:11 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A622521F9FB8 for ; Wed, 26 Jun 2013 00:52:09 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A3F0893C1AF for ; Wed, 26 Jun 2013 07:52:07 +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: <51C9CC99.7020007@dcrocker.net> Date: Wed, 26 Jun 2013 09:52:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A4626E7-A598-412C-A03C-2CE678A6DFE3@edvina.net> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> To: "stir@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 07:52:11 -0000 25 jun 2013 kl. 19:00 skrev Dave Crocker : >> If that's truly the case - that we plan to do an in-band first, and = when that's done then an out-of-band one - then I propose we remove the = out-of-band from the charter. We can always re-charter and add new = deliverables when we're ready for an out-of-band mechanism; we = re-charter all the time in RAI groups. We might even decide by then = that an out-of-band mechanism should work very differently, or that = defining one isn't necessary, or that we don't have the right = participants in the IETF to do so successfully. >>=20 >> For now, by removing it from the charter, we can focus on one = solution and not have to debate about this aspect during the BOF nor WG = meetings. I am very worried that we won't have a successful BOF - where = I measure "success" as reaching consensus to create a Working Group. = Lengthy microphone debates kill BOFs, in my experience. (and I recognize = you and Russ and others have seen far more BOFs than I have, so maybe = I've just been to the wrong ones ;) >=20 >=20 > +1. >=20 > Narrow, clear focus. >=20 > Good. Agree. /O= From oej@edvina.net Wed Jun 26 01:09: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 AE16B11E819E for ; Wed, 26 Jun 2013 01:09:28 -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 w7VHGEZWVVbp for ; Wed, 26 Jun 2013 01:09:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28811E80E4 for ; Wed, 26 Jun 2013 01:09:24 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E248893C2A3; Wed, 26 Jun 2013 08:09:23 +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: <00C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> Date: Wed, 26 Jun 2013 10:09:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) Cc: "stir@ietf.org" , "Olle E. Johansson" , "timothy.dwight@verizon.com" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 08:09:28 -0000 25 jun 2013 kl. 21:10 skrev Michael Hammer = : > I think your last statement is the gist of this issue. > Is routing and authentication within a private network in scope for = this > group. > I think not. I do agree. Now, the question is if the situation with two private networks peering = using E.164 phone numbers is within scope? We will see more and more of that and the definition of "service = provider" is less and less clear. There some sort of border we're looking for where a call using an E.164 = number as a caller ID leaves a "domain" or "realm". /O >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Dwight, Timothy M (Tim) > Sent: Tuesday, June 25, 2013 10:16 AM > To: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 > It's not just an issue of what gets displayed. The PBX may have = different > policies for internal and external calls. It's not necessarily the = case > that every PBX in an Enterprise knows the E.164 numbers of every other = PBX > in the Enterprise. That's why they have private dial plans... >=20 > I won't comment on what works poorly or well, other than to note that = most > solutions can be made to fall into either category. >=20 > This may all be moot if it's agreed to exclude calls that originate = and > terminate within the same Enterprise, from this activity. >=20 > Tim >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Paul > Kyzivat > Sent: Tuesday, June 25, 2013 12:05 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 > On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: >> What about the private dial plan / sip trunking scenarios? In that = case > it may be desired to deliver the FROM header in "non-canonical" = format, so > that the recipient can know that this was an "internal" call. >=20 > I have never understood this argument. >=20 > If the call is "internal" (because the caller and callee are in the = same > enterprise, regardless of whether the call transited a public hop), = then the > recipient should be able to recognize that the From, in E.164 format, = is an > internal number. If it wants, the receiving device can apply the = inverse of > the dial plan to the number to produce an internal dial string that > represents the caller, and display that as the caller id. >=20 > I have experienced behavior such as you describe, that worked poorly, > because individual sites of the enterprise have different dial plans, = so > that the "local" number at one site has a different meaning when = displayed > as caller id for the callee at a different site. >=20 > If the calling number has no E.164 equivalent, then the = telephone-subscriber > syntax used in both TEL and SIP has a phone-context param that can be = used > to represent the private number in a globally unique way. >=20 > Thanks, > Paul >=20 >> tim >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Henning Schulzrinne >> Sent: Tuesday, June 25, 2013 10:13 AM >> To: philippe.fouquart@orange.com; Hadriel Kaplan >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >> The signed entity would always be a full E.164 number, as the theory = is > that both calling and called carrier are able to derive that canonical > format, as they need to do today for SS7 signaling, CNAM and = intercarrier > compensation. Thus, the originating carrier would never sign = 212-555-1212, > but only +12125551212. >>=20 >> ________________________________________ >> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of=20 >> philippe.fouquart@orange.com [philippe.fouquart@orange.com] >> Sent: Tuesday, June 25, 2013 8:49 AM >> To: Hadriel Kaplan >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >> Hadriel, >>=20 >> We seem to be talking past each other. I interpreted your comment as: >> a) the signing of the TN - who may be done directly or on behalf of=20= >> the holder - may use a non canonical form of TN, >> b) supposing in-band, that signing would then be conveyed in some way=20= >> yet TBD untouched to the verifier, and >> c) the verifier would then have to compute that "canonical form" to > eventually assert authenticity. >>=20 >> My comment was that I didn't see how the verifier could reasonably do = c) > without prior knowledge of the numbering plan of TN, so either the = signer > and the verifier implicitly share the function according to which you = can > translate the non canonical form into a canonical form (eg they are on = the > same dialing plan) or I don't see how this could work. Say = TN=3D+12125551212, > but a) signs 2125551212 how could c) be correct unless the verifier = knows > that it's an NANP number for which adding +1 upfront is enough to make = it a > full E.164 number? >>=20 >> What am I missing here? >>=20 >> I definitely don't want to force anyone doing anything with the = format of > their CLI, I was merely observing that, with the same examples, if a) > proceeds with 2125551212 and c) is not in the NANP number or doesn't = know > it's an NANP number, then I didn't see how it could determine what > canonicalization function to apply. >>=20 >> Philippe Fouquart >> Orange Labs Networks >> +33 (0) 1 45 29 58 13 >>=20 >>=20 >> -----Original Message----- >> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >> Sent: Tuesday, June 25, 2013 8:00 AM >> To: FOUQUART Philippe OLNC/OLN >> Cc: Rosen, Brian; stir@ietf.org >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>=20 >>=20 >> On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >>> I understand it may not be the priority here but as a target I think = that > grand plan could remain in scope, and again, I think the extra = flexibility > for a signer is quite minimal in most dialing plans and the added = complexity > for the receiver is in my view not worth it. >>=20 >> We could certainly have an RFC require the signing domain to generate = a > To/=46rom URI of E.164 and 'user=3Dpart' and all, but I don't see how = that would > really succeed: >>=20 >> 1) =46rom a practical matter, legacy operators can't change all their > systems to suddenly use a new format; so you'd be forcing them to do = the > signing function on their egress SBCs. While I expect that to be a = common > scenario anyway, I don't think we'd want to force people to doing it = there, > or on any SBCs for that matter. It should be possible to do the = signing > anywhere on any system type, so long as the signing system knows the = caller > can claim the E.164 number. >>=20 >> 2) Even if the originator/signer does it that way, by the time the > terminating domain receives the call it will have come through transit > providers who already today change the To/=46rom URIs. >>=20 >>=20 >>> Finally the irony of not providing a full canonical form is that an=20= >>> increasing number of user data profiles contains the subscriber=20 >>> number in its full E.164 format, so it may actually require *extra >>> work* to provide a different format in a CgP-related header. (I'm = not=20 >>> referring to R-Us which in the world I live in generally have to be=20= >>> manipulated as some point to see the light of the CdP party's=20 >>> endpoint or they'll just never get there - if this group were to=20 >>> address such use cases, the logic may have to be different IMHO) >>=20 >> Oh you don't have to provide it in a different format - if you = provide it > in an E.164 format today you can continue to with STIR, and you can = even > change from your current local format to using an E.164 format. We = just > wouldn't be relying on everyone changing over, for STIR to work. >>=20 >> -hadriel >>=20 >>=20 >>=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 >> _______________________________________________ >> 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 >=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 philippe.fouquart@orange.com Wed Jun 26 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 002DA21E80F9 for ; Wed, 26 Jun 2013 02:18:52 -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, 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 pDSd5I2dbH51 for ; Wed, 26 Jun 2013 02:18:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFE21E8122 for ; Wed, 26 Jun 2013 02:18:47 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9E11132535E; Wed, 26 Jun 2013 11:18:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 810FE35C058; Wed, 26 Jun 2013 11:18:41 +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; Wed, 26 Jun 2013 11:18:41 +0200 From: To: Hadriel Kaplan , "Rosen, Brian" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMIAAz44AgABx/wCAAE85gIABHynA Date: Wed, 26 Jun 2013 09:18:40 +0000 Message-ID: <13385_1372238321_51CAB1F1_13385_1560_1_B5939C6860701C49AA39C5DA5189448B0AB0DE@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com> <8B9DE92F-CE1E-42C7-A5FC-A477B47B1717@oracle.com> In-Reply-To: <8B9DE92F-CE1E-42C7-A5FC-A477B47B1717@oracle.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.5.21.113319 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 09:18:53 -0000 Such an approach on From vs PAI would be fine with me.=20 > My evidence of that is that terminating carriers use the source info a LO= T,=20 > on a bunch of systems: voicemail servers, IVRs, CNAM servers, conf bridge= s,=20 > billing systems, etc.=20=20 My evidence is also that they do, indeed.=20 > And of course they ultimately display them as caller-ids on their subscri= ber's phones. I guess we'll be saying the same thing but actually they do not, strictly s= peaking because they've always made a difference between the dialing plan a= nd the numbering plan, ie what the user sees/uses vs. what the "network" us= es. What is displayed is generally the result of a CLIP service. For exampl= e, a DDI/DID number of a SIP trunking service conveyed as an E.164 number C= LI would generally be displayed in three different ways depending on whethe= r the call terminates on the same PBX, on a landline in the same country or= on a mobile phone.=20=20=20 > > Alternatively, is it reasonable for the ingress SBC to rewrite it so it= can be? > > The SBC already rewrite the From - they convert it into a format the loca= l=20 > operator can understand/use They can, but they may not have to, luckily enough. The extent to which thi= s is necessary really depends on the kind of traffic they handle.=20=20=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com]=20 Sent: Tuesday, June 25, 2013 7:32 PM To: Rosen, Brian Cc: FOUQUART Philippe OLNC/OLN; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 25, 2013, at 8:48 AM, "Rosen, Brian" wrote: > I get that termination TN has to be able to be canonicalized, because rou= ting has to work. >=20 > What do we do about From? >=20 > As it is today, can the terminating domain extract a canonical e.164 from= what is actually sent? Yes, I think it's a very safe bet that the terminating domain can figure ou= t what the E.164 source identity is. My evidence of that is that terminati= ng carriers use the source info a LOT, on a bunch of systems: voicemail ser= vers, IVRs, CNAM servers, conf bridges, billing systems, etc. And of cours= e they ultimately display them as caller-ids on their subscriber's phones. And the transit carriers can too, because they also use the source identity= : for billing and for source-based routing (which is common for transits). > Alternatively, is it reasonable for the ingress SBC to rewrite it so it c= an be? The SBC already rewrite the From - they convert it into a format the local = operator can understand/use, so that it works in those systems I mentioned = above. The SBCs can determine what the equivalent E.164 number is so that they can= do the verifying, but they couldn't convert the From into a "compliant" E.= 164 format, because then it won't work on those systems I mentioned above. > Or do we rely on P-A-I? Well... whether to use the From or PAI as the source identity is a bit tric= ky. PAI is also very commonly used for some of the things we'd want to hav= e validated caller-ids for, and goes across/between some carriers too. In = other words, some of those systems I mentioned above use the PAI instead of= the From, but I think we'd be ok saying in the RFC to validate the From, a= nd if the From doesn't match the PAI then leave it up to local policy to de= cide what to do. 3GPP will go define what to do in that circumstance for I= MS, for example. -hadriel ___________________________________________________________________________= ______________________________________________ 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 philippe.fouquart@orange.com Wed Jun 26 03:05: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 17FE021F8FE5 for ; Wed, 26 Jun 2013 03:05:50 -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, 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 1p9mY+hBpwEa for ; Wed, 26 Jun 2013 03:05:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 49C7321E80D7 for ; Wed, 26 Jun 2013 03:05:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B3FC118CC25; Wed, 26 Jun 2013 12:05:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9031827C053; Wed, 26 Jun 2013 12:05:44 +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, 26 Jun 2013 12:05:44 +0200 From: To: Henning Schulzrinne , "Dwight, Timothy M (Tim)" , Hadriel Kaplan Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMIAAz44AgACHpfCAABKwAIAACiiAgAALLgCAAAl9AIAAGYGAgAEcu+A= Date: Wed, 26 Jun 2013 10:05:43 +0000 Message-ID: <28310_1372241144_51CABCF8_28310_5312_1_B5939C6860701C49AA39C5DA5189448B0AD14B@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <11549_1371658326_51C1D855_11549_4779_1_B5939C6860701C49AA39C5DA5189448B0A3D4A@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2D1B2935-AC51-4EA1-9377-63B67DD15086@neustar.biz> <23180_1371721060_51C2CD64_23180_9386_1_B5939C6860701C49AA39C5DA5189448B0A3FAE@PEXCVZYM12.corporate.adroot.infra.ftgroup> <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> , <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> , <2B0F677F0B95454297753F58D4A07FA30127E3E0A6@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.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.26.75421 Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 10:05:50 -0000 I wouldn't think it is either. I suppose the DDI numbers might indeed be tr= eated exactly as E.164 numbers (by and large they are, in the (SIP) network= s I'm familiar with) but the non DDIs will remain a bit of a problem with t= he current logic as would be the case of short codes in the public dialing = plan anyway. I'm fine with leaving all of those aside.=20 Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Tuesday, June 25, 2013 8:34 PM To: Dwight, Timothy M (Tim); FOUQUART Philippe OLNC/OLN; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) I don't think number spoofing within enterprise networks or within a single= carrier network is a major problem at the moment, so I'm less worried abou= t supporting that case if it requires major contortions. I'm a bit worried about having too many identifiers in the same message - w= e want to make sure that the number presented to the user, via caller-ID, c= an be trusted, rather than some other string that the user cannot see and m= ay well differ. While MIM attacks are not a major concern, if you can essen= tially slap a signed block into just about any signaling message, and the c= allerID is interpreted as signed even though the signed block refers to som= e completely different number, this seems like a recipe for mischief. ________________________________________ From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Dwight, Ti= mothy M (Tim) [timothy.dwight@verizon.com] Sent: Tuesday, June 25, 2013 1:02 PM To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) So you're proposing that SIP trunking services would be exempted from these= requirements? That's one solution I suppose. I'm not opposed. You may have more experience that me with SIP trunking services, but in my = limited experience the PBX often needs to know (or at least, will behave di= fferently if it knows) that the call was from an on-net user. tim -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Tuesday, June 25, 2013 11:29 AM To: Dwight, Timothy M (Tim); philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) Traffic that stays within a private network is probably not a major concern= , at least for the "provider-validates" scenario. My understanding is that in order to deliver usable caller ID to SIP phones= , SIP trunking providers normalize phone numbers except maybe for in-house = extensions. ________________________________________ From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com] Sent: Tuesday, June 25, 2013 11:48 AM To: Henning Schulzrinne; philippe.fouquart@orange.com; Hadriel Kaplan Cc: Rosen, Brian; stir@ietf.org Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?) What about the private dial plan / sip trunking scenarios? In that case it= may be desired to deliver the FROM header in "non-canonical" format, so th= at the recipient can know that this was an "internal" call. tim _______________________________________________ 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 md3135@att.com Wed Jun 26 04:04: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 BBEAC21E8133 for ; Wed, 26 Jun 2013 04:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESG+eUSm3NM4 for ; Wed, 26 Jun 2013 04:04:09 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7A21E8116 for ; Wed, 26 Jun 2013 04:04:08 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9aacac15.4a35f940.35697.00-586.96944.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 11:04:09 +0000 (UTC) X-MXL-Hash: 51cacaa919b02122-5e9ef461d244c1f519979a3952ceb7f9d1237626 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5aacac15.0.35682.00-469.96883.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 26 Jun 2013 11:04:08 +0000 (UTC) X-MXL-Hash: 51cacaa84961ab2c-4d6e7dd5bab5d50405d544af2e24967448c14ebc 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 r5QB44Ho000568; Wed, 26 Jun 2013 07:04:05 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5QB3nLE000340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 07:03:57 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 26 Jun 2013 11:03:31 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 07:03:39 -0400 From: "DOLLY, MARTIN C" To: "Olle E. Johansson" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHOckIO9Ube0wumgUCN8mAR+HJsz5lH1Rvs Date: Wed, 26 Jun 2013 11:03:38 +0000 Message-ID: <08FAC8EF-BC73-49D7-A36C-5617C43685FA@att.com> References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net>, <2A4626E7-A598-412C-A03C-2CE678A6DFE3@edvina.net> In-Reply-To: <2A4626E7-A598-412C-A03C-2CE678A6DFE3@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Ecp/toaC c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=5-KlvN02] X-AnalysisOut: [AAAA:8 a=b8OvNEjoAAAA:8 a=48vgC7mUAAAA:8 a=OPD8kOr9rIa4kv3] X-AnalysisOut: [kOZoA:9 a=CjuIK1q_8ugA:10 a=aFo64ATDO6kA:10 a=E1Snkw02GREA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=DNyxedVry5mOHFWT:21 a=Ogoa4DWku7iW] X-AnalysisOut: [tGrL:21] Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 11:04:14 -0000 Agree with Dave Martin Dolly AT&T=20 Sent from my iPhone On Jun 26, 2013, at 3:52 AM, "Olle E. Johansson" wrote: >=20 > 25 jun 2013 kl. 19:00 skrev Dave Crocker : >=20 >>> If that's truly the case - that we plan to do an in-band first, and whe= n that's done then an out-of-band one - then I propose we remove the out-of= -band from the charter. We can always re-charter and add new deliverables = when we're ready for an out-of-band mechanism; we re-charter all the time i= n RAI groups. We might even decide by then that an out-of-band mechanism s= hould work very differently, or that defining one isn't necessary, or that = we don't have the right participants in the IETF to do so successfully. >>>=20 >>> For now, by removing it from the charter, we can focus on one solution = and not have to debate about this aspect during the BOF nor WG meetings. I= am very worried that we won't have a successful BOF - where I measure "suc= cess" as reaching consensus to create a Working Group. Lengthy microphone = debates kill BOFs, in my experience. (and I recognize you and Russ and othe= rs have seen far more BOFs than I have, so maybe I've just been to the wron= g ones ;) >>=20 >>=20 >> +1. >>=20 >> Narrow, clear focus. >>=20 >> Good. >=20 > Agree. >=20 > /O > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From andrew.hutton@siemens-enterprise.com Wed Jun 26 06:50: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 B3E4021E8126 for ; Wed, 26 Jun 2013 06:50:34 -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=[AWL=0.000, 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 oRCNy2oYmtYC for ; Wed, 26 Jun 2013 06:50:30 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 090AB11E81B8 for ; Wed, 26 Jun 2013 06:50:30 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 488D01EB85C0; Wed, 26 Jun 2013 15:50:27 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 15:50:27 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , Michael Hammer Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb407rT0uZGkmimelssQZO+Zk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAC4W4CAAH3kEA== Date: Wed, 26 Jun 2013 13:50:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net> References: <8726A5FA-60A8-442D-B669-1DA2373FDCC6@neustar.biz> <1526_1371737877_51C30F15_1526_2424_1_B5939C6860701C49AA39C5DA5189448B0A4B7E@PEXCVZYM12.corporate.adroot.infra.ftgroup> <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> In-Reply-To: <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "timothy.dwight@verizon.com" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 13:50:35 -0000 We need to think carefully about terminology here and stop using terms such= as "private network", "service provider" and "enterprise network" which ar= e open to interpretation. These boundaries are becoming more and more blurr= ed. Increasingly we see vendors offering cloud based communications / UC to ent= erprises so an enterprise can easily subscribe to cloud based communication= s services. In this case the boundaries are less clear. So I agree with Olle we need clarity on what is we are actually trying to s= olve and the trust boundaries to which it applies. Maybe it will become cl= earer as I catch up with the long list of e-mails I still have to read but = I am concerned by the terminology we are using. Regards Andy > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Olle E. Johansson > Sent: 26 June 2013 09:09 > To: Michael Hammer > Cc: stir@ietf.org; Olle E. Johansson; timothy.dwight@verizon.com; > pkyzivat@alum.mit.edu > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 >=20 > 25 jun 2013 kl. 21:10 skrev Michael Hammer > : >=20 > > I think your last statement is the gist of this issue. > > Is routing and authentication within a private network in scope for > this > > group. > > I think not. >=20 > I do agree. > Now, the question is if the situation with two private networks peering > using > E.164 phone numbers is within scope? >=20 > We will see more and more of that and the definition of "service > provider" is less and less clear. >=20 > There some sort of border we're looking for where a call using an E.164 > number as a caller ID > leaves a "domain" or "realm". >=20 > /O > > > > Mike > > > > > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of > > Dwight, Timothy M (Tim) > > Sent: Tuesday, June 25, 2013 10:16 AM > > To: Paul Kyzivat; stir@ietf.org > > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > > It's not just an issue of what gets displayed. The PBX may have > different > > policies for internal and external calls. It's not necessarily the > case > > that every PBX in an Enterprise knows the E.164 numbers of every > other PBX > > in the Enterprise. That's why they have private dial plans... > > > > I won't comment on what works poorly or well, other than to note that > most > > solutions can be made to fall into either category. > > > > This may all be moot if it's agreed to exclude calls that originate > and > > terminate within the same Enterprise, from this activity. > > > > Tim > > > > > > -----Original Message----- > > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Paul > > Kyzivat > > Sent: Tuesday, June 25, 2013 12:05 PM > > To: stir@ietf.org > > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > > On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: > >> What about the private dial plan / sip trunking scenarios? In that > case > > it may be desired to deliver the FROM header in "non-canonical" > format, so > > that the recipient can know that this was an "internal" call. > > > > I have never understood this argument. > > > > If the call is "internal" (because the caller and callee are in the > same > > enterprise, regardless of whether the call transited a public hop), > then the > > recipient should be able to recognize that the From, in E.164 format, > is an > > internal number. If it wants, the receiving device can apply the > inverse of > > the dial plan to the number to produce an internal dial string that > > represents the caller, and display that as the caller id. > > > > I have experienced behavior such as you describe, that worked poorly, > > because individual sites of the enterprise have different dial plans, > so > > that the "local" number at one site has a different meaning when > displayed > > as caller id for the callee at a different site. > > > > If the calling number has no E.164 equivalent, then the telephone- > subscriber > > syntax used in both TEL and SIP has a phone-context param that can be > used > > to represent the private number in a globally unique way. > > > > Thanks, > > Paul > > > >> tim > >> > >> -----Original Message----- > >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > >> Of Henning Schulzrinne > >> Sent: Tuesday, June 25, 2013 10:13 AM > >> To: philippe.fouquart@orange.com; Hadriel Kaplan > >> Cc: Rosen, Brian; stir@ietf.org > >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > >> > >> The signed entity would always be a full E.164 number, as the theory > is > > that both calling and called carrier are able to derive that > canonical > > format, as they need to do today for SS7 signaling, CNAM and > intercarrier > > compensation. Thus, the originating carrier would never sign 212-555- > 1212, > > but only +12125551212. > >> > >> ________________________________________ > >> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of > >> philippe.fouquart@orange.com [philippe.fouquart@orange.com] > >> Sent: Tuesday, June 25, 2013 8:49 AM > >> To: Hadriel Kaplan > >> Cc: Rosen, Brian; stir@ietf.org > >> Subject: Re: [stir] URI formats (was RE: Do we agree on the > basics?) > >> > >> Hadriel, > >> > >> We seem to be talking past each other. I interpreted your comment > as: > >> a) the signing of the TN - who may be done directly or on behalf of > >> the holder - may use a non canonical form of TN, > >> b) supposing in-band, that signing would then be conveyed in some > way > >> yet TBD untouched to the verifier, and > >> c) the verifier would then have to compute that "canonical form" to > > eventually assert authenticity. > >> > >> My comment was that I didn't see how the verifier could reasonably > do c) > > without prior knowledge of the numbering plan of TN, so either the > signer > > and the verifier implicitly share the function according to which you > can > > translate the non canonical form into a canonical form (eg they are > on the > > same dialing plan) or I don't see how this could work. Say > TN=3D+12125551212, > > but a) signs 2125551212 how could c) be correct unless the verifier > knows > > that it's an NANP number for which adding +1 upfront is enough to > make it a > > full E.164 number? > >> > >> What am I missing here? > >> > >> I definitely don't want to force anyone doing anything with the > format of > > their CLI, I was merely observing that, with the same examples, if a) > > proceeds with 2125551212 and c) is not in the NANP number or doesn't > know > > it's an NANP number, then I didn't see how it could determine what > > canonicalization function to apply. > >> > >> Philippe Fouquart > >> Orange Labs Networks > >> +33 (0) 1 45 29 58 13 > >> > >> > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > >> Sent: Tuesday, June 25, 2013 8:00 AM > >> To: FOUQUART Philippe OLNC/OLN > >> Cc: Rosen, Brian; stir@ietf.org > >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > >> > >> > >> On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: > >>> I understand it may not be the priority here but as a target I > think that > > grand plan could remain in scope, and again, I think the extra > flexibility > > for a signer is quite minimal in most dialing plans and the added > complexity > > for the receiver is in my view not worth it. > >> > >> We could certainly have an RFC require the signing domain to > generate a > > To/From URI of E.164 and 'user=3Dpart' and all, but I don't see how > that would > > really succeed: > >> > >> 1) From a practical matter, legacy operators can't change all their > > systems to suddenly use a new format; so you'd be forcing them to do > the > > signing function on their egress SBCs. While I expect that to be a > common > > scenario anyway, I don't think we'd want to force people to doing it > there, > > or on any SBCs for that matter. It should be possible to do the > signing > > anywhere on any system type, so long as the signing system knows the > caller > > can claim the E.164 number. > >> > >> 2) Even if the originator/signer does it that way, by the time the > > terminating domain receives the call it will have come through > transit > > providers who already today change the To/From URIs. > >> > >> > >>> Finally the irony of not providing a full canonical form is that an > >>> increasing number of user data profiles contains the subscriber > >>> number in its full E.164 format, so it may actually require *extra > >>> work* to provide a different format in a CgP-related header. (I'm > not > >>> referring to R-Us which in the world I live in generally have to be > >>> manipulated as some point to see the light of the CdP party's > >>> endpoint or they'll just never get there - if this group were to > >>> address such use cases, the logic may have to be different IMHO) > >> > >> Oh you don't have to provide it in a different format - if you > provide it > > in an E.164 format today you can continue to with STIR, and you can > even > > change from your current local format to using an E.164 format. We > just > > wouldn't be relying on everyone changing over, for STIR to work. > >> > >> -hadriel > >> > >> > >> > >> > ______________________________________________________________________ > >> ___________________________________________________ > >> > >> 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. > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pkyzivat@alum.mit.edu Wed Jun 26 07: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 C4AE221F84AA for ; Wed, 26 Jun 2013 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=0.437, 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 MrrWtcgzGN6L for ; Wed, 26 Jun 2013 07:02:46 -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 D919021F9967 for ; Wed, 26 Jun 2013 07:02:44 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id t0oX1l0051c6gX85422ksP; Wed, 26 Jun 2013 14:02:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id t22k1l0023ZTu2S3j22ksr; Wed, 26 Jun 2013 14:02:44 +0000 Message-ID: <51CAF483.9000305@alum.mit.edu> Date: Wed, 26 Jun 2013 10:02:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372255364; bh=mpf2/IYwcHtBcDJs/USemlAZUTA9tl8gy8Okfma6nU4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dp8/N4sHHvpDh7uWtHEvhxSs9qhGOOebtLyCyLfvJhid4URF7iLJ7ARl8EhgU9IJX aXqR/dNnuWpz6nTT0d4xlapKTxJKTggUZ5Gh1DI4vOA6wcJX+c5JmFsEqPNzK99FzZ Apkxy0SEUPlaHFV+v78jlcWs6DISJW3YHq8w5aKqjJxQJML0jPGIDUi/2IHxP9r+EE pnXi5XeOpyNcu9QZazagY8r0dzOciqcOAH/fzM6WkL+jXvYwvqxei2QaFgcZFk1u4s dwB4eSKPGHIJ0mm+YaxwCRQUthVNd6UEJYFveyG9G95uu5sg8bcPPpDXWNKAobbaYl 3G9itK+WTa7sQ== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 14:02:50 -0000 On 6/26/13 9:50 AM, Hutton, Andrew wrote: > > We need to think carefully about terminology here and stop using terms such as "private network", "service provider" and "enterprise network" which are open to interpretation. These boundaries are becoming more and more blurred. > > Increasingly we see vendors offering cloud based communications / UC to enterprises so an enterprise can easily subscribe to cloud based communications services. In this case the boundaries are less clear. > > So I agree with Olle we need clarity on what is we are actually trying to solve and the trust boundaries to which it applies. Maybe it will become clearer as I catch up with the long list of e-mails I still have to read but I am concerned by the terminology we are using. I agree. ISTM that we can consider out of scope cases where caller, callee, and the entire path are under control of a single organization (e.g., a business' private phone network). But they can still opt in for for regulatory reasons (e.g., a carrier) or just because they want to. And I think we could rule out cases where the numbers aren't covered by a canonicalization mechanism understood by both ends. That might cover numbers that don't have E.164 representatons. But we *could* allow *some* of those to be covered by parameters to telephone-subscriber (such as phone-context). ISTM that STIR could cover any case not excluded by the above. Thanks, Paul > Regards > Andy > > > > >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >> Olle E. Johansson >> Sent: 26 June 2013 09:09 >> To: Michael Hammer >> Cc: stir@ietf.org; Olle E. Johansson; timothy.dwight@verizon.com; >> pkyzivat@alum.mit.edu >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >> >> >> 25 jun 2013 kl. 21:10 skrev Michael Hammer >> : >> >>> I think your last statement is the gist of this issue. >>> Is routing and authentication within a private network in scope for >> this >>> group. >>> I think not. >> >> I do agree. >> Now, the question is if the situation with two private networks peering >> using >> E.164 phone numbers is within scope? >> >> We will see more and more of that and the definition of "service >> provider" is less and less clear. >> >> There some sort of border we're looking for where a call using an E.164 >> number as a caller ID >> leaves a "domain" or "realm". >> >> /O >>> >>> Mike >>> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of >>> Dwight, Timothy M (Tim) >>> Sent: Tuesday, June 25, 2013 10:16 AM >>> To: Paul Kyzivat; stir@ietf.org >>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>> >>> It's not just an issue of what gets displayed. The PBX may have >> different >>> policies for internal and external calls. It's not necessarily the >> case >>> that every PBX in an Enterprise knows the E.164 numbers of every >> other PBX >>> in the Enterprise. That's why they have private dial plans... >>> >>> I won't comment on what works poorly or well, other than to note that >> most >>> solutions can be made to fall into either category. >>> >>> This may all be moot if it's agreed to exclude calls that originate >> and >>> terminate within the same Enterprise, from this activity. >>> >>> Tim >>> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul >>> Kyzivat >>> Sent: Tuesday, June 25, 2013 12:05 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>> >>> On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: >>>> What about the private dial plan / sip trunking scenarios? In that >> case >>> it may be desired to deliver the FROM header in "non-canonical" >> format, so >>> that the recipient can know that this was an "internal" call. >>> >>> I have never understood this argument. >>> >>> If the call is "internal" (because the caller and callee are in the >> same >>> enterprise, regardless of whether the call transited a public hop), >> then the >>> recipient should be able to recognize that the From, in E.164 format, >> is an >>> internal number. If it wants, the receiving device can apply the >> inverse of >>> the dial plan to the number to produce an internal dial string that >>> represents the caller, and display that as the caller id. >>> >>> I have experienced behavior such as you describe, that worked poorly, >>> because individual sites of the enterprise have different dial plans, >> so >>> that the "local" number at one site has a different meaning when >> displayed >>> as caller id for the callee at a different site. >>> >>> If the calling number has no E.164 equivalent, then the telephone- >> subscriber >>> syntax used in both TEL and SIP has a phone-context param that can be >> used >>> to represent the private number in a globally unique way. >>> >>> Thanks, >>> Paul >>> >>>> tim >>>> >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>>> Of Henning Schulzrinne >>>> Sent: Tuesday, June 25, 2013 10:13 AM >>>> To: philippe.fouquart@orange.com; Hadriel Kaplan >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>> >>>> The signed entity would always be a full E.164 number, as the theory >> is >>> that both calling and called carrier are able to derive that >> canonical >>> format, as they need to do today for SS7 signaling, CNAM and >> intercarrier >>> compensation. Thus, the originating carrier would never sign 212-555- >> 1212, >>> but only +12125551212. >>>> >>>> ________________________________________ >>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>> philippe.fouquart@orange.com [philippe.fouquart@orange.com] >>>> Sent: Tuesday, June 25, 2013 8:49 AM >>>> To: Hadriel Kaplan >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the >> basics?) >>>> >>>> Hadriel, >>>> >>>> We seem to be talking past each other. I interpreted your comment >> as: >>>> a) the signing of the TN - who may be done directly or on behalf of >>>> the holder - may use a non canonical form of TN, >>>> b) supposing in-band, that signing would then be conveyed in some >> way >>>> yet TBD untouched to the verifier, and >>>> c) the verifier would then have to compute that "canonical form" to >>> eventually assert authenticity. >>>> >>>> My comment was that I didn't see how the verifier could reasonably >> do c) >>> without prior knowledge of the numbering plan of TN, so either the >> signer >>> and the verifier implicitly share the function according to which you >> can >>> translate the non canonical form into a canonical form (eg they are >> on the >>> same dialing plan) or I don't see how this could work. Say >> TN=+12125551212, >>> but a) signs 2125551212 how could c) be correct unless the verifier >> knows >>> that it's an NANP number for which adding +1 upfront is enough to >> make it a >>> full E.164 number? >>>> >>>> What am I missing here? >>>> >>>> I definitely don't want to force anyone doing anything with the >> format of >>> their CLI, I was merely observing that, with the same examples, if a) >>> proceeds with 2125551212 and c) is not in the NANP number or doesn't >> know >>> it's an NANP number, then I didn't see how it could determine what >>> canonicalization function to apply. >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> >>>> -----Original Message----- >>>> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >>>> Sent: Tuesday, June 25, 2013 8:00 AM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>>> >>>> >>>> On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >>>>> I understand it may not be the priority here but as a target I >> think that >>> grand plan could remain in scope, and again, I think the extra >> flexibility >>> for a signer is quite minimal in most dialing plans and the added >> complexity >>> for the receiver is in my view not worth it. >>>> >>>> We could certainly have an RFC require the signing domain to >> generate a >>> To/From URI of E.164 and 'user=part' and all, but I don't see how >> that would >>> really succeed: >>>> >>>> 1) From a practical matter, legacy operators can't change all their >>> systems to suddenly use a new format; so you'd be forcing them to do >> the >>> signing function on their egress SBCs. While I expect that to be a >> common >>> scenario anyway, I don't think we'd want to force people to doing it >> there, >>> or on any SBCs for that matter. It should be possible to do the >> signing >>> anywhere on any system type, so long as the signing system knows the >> caller >>> can claim the E.164 number. >>>> >>>> 2) Even if the originator/signer does it that way, by the time the >>> terminating domain receives the call it will have come through >> transit >>> providers who already today change the To/From URIs. >>>> >>>> >>>>> Finally the irony of not providing a full canonical form is that an >>>>> increasing number of user data profiles contains the subscriber >>>>> number in its full E.164 format, so it may actually require *extra >>>>> work* to provide a different format in a CgP-related header. (I'm >> not >>>>> referring to R-Us which in the world I live in generally have to be >>>>> manipulated as some point to see the light of the CdP party's >>>>> endpoint or they'll just never get there - if this group were to >>>>> address such use cases, the logic may have to be different IMHO) >>>> >>>> Oh you don't have to provide it in a different format - if you >> provide it >>> in an E.164 format today you can continue to with STIR, and you can >> even >>> change from your current local format to using an E.164 format. We >> just >>> wouldn't be relying on everyone changing over, for STIR to work. >>>> >>>> -hadriel >>>> >>>> >>>> >>>> >> ______________________________________________________________________ >>>> ___________________________________________________ >>>> >>>> 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. >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 Jun 26 08:33: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 1245D11E811B for ; Wed, 26 Jun 2013 08:33:55 -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 byhbSU44QcEm for ; Wed, 26 Jun 2013 08:33:50 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 6FB3611E80EF for ; Wed, 26 Jun 2013 08:33:50 -0700 (PDT) Received: (qmail 2142 invoked by uid 0); 26 Jun 2013 15:33:23 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 26 Jun 2013 15:33: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:Cc:To:From; bh=0Bh6LzJKvUVIDwCjVpC5dArKElgwet877IN/RwCl92A=; b=dJ6+ejREuY+5bZdNjE0U2o/QrhcjAQ7Lj7MZsVISOc0ZBV9Nq8ielUTdBfLA1ujGacFRNKE4lS1ggPYi/7jZqF6zbOhNT3e1b6sydBoGpkmv/RYGUsniYtUlNfeq4Wne; Received: from [72.66.111.124] (port=50269 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Urrik-00056f-JQ; Wed, 26 Jun 2013 09:33:22 -0600 From: "Richard Shockey" To: "'Wendt, Chris'" , References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> In-Reply-To: <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> Date: Wed, 26 Jun 2013 11:33:19 -0400 Message-ID: <009001ce7282$7d68acd0$783a0670$@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: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJJmyPghg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Henning Schulzrinne' , 'Hadriel Kaplan' , 'Brian Rosen' Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 15:33:55 -0000 +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF to do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just been to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 michael.hammer@yaanatech.com Wed Jun 26 09:16: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 E4BBC21F8459 for ; Wed, 26 Jun 2013 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, 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 eDFfMairZ0yI for ; Wed, 26 Jun 2013 09:15:55 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9348821E8087 for ; Wed, 26 Jun 2013 09:15:55 -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, 26 Jun 2013 09:15:53 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26A//+uonA= Date: Wed, 26 Jun 2013 16:15:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0DA11@EX2K10MB1.corp.yaanatech.com> References: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net> <51CAF483.9000305@alum.mit.edu> In-Reply-To: <51CAF483.9000305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006E_01CE724D.C15E3CF0" MIME-Version: 1.0 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 16:16:00 -0000 ------=_NextPart_000_006E_01CE724D.C15E3CF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I would not confuse the underlying environment and transport between signaling elements. We are talking about the signaling layer here and only functions on those elements that process the SIP or SS7. Whether you want to call it inter-domain versus public or private, the essence is still the same. Intra-administration you can do what you want, but when you pass it to some other independent entity, perhaps some rules apply. That does not mean that the intra-domain experience cannot also follow suite, if they find it useful. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, June 26, 2013 7:03 AM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On 6/26/13 9:50 AM, Hutton, Andrew wrote: > > We need to think carefully about terminology here and stop using terms such as "private network", "service provider" and "enterprise network" which are open to interpretation. These boundaries are becoming more and more blurred. > > Increasingly we see vendors offering cloud based communications / UC to enterprises so an enterprise can easily subscribe to cloud based communications services. In this case the boundaries are less clear. > > So I agree with Olle we need clarity on what is we are actually trying to solve and the trust boundaries to which it applies. Maybe it will become clearer as I catch up with the long list of e-mails I still have to read but I am concerned by the terminology we are using. I agree. ISTM that we can consider out of scope cases where caller, callee, and the entire path are under control of a single organization (e.g., a business' private phone network). But they can still opt in for for regulatory reasons (e.g., a carrier) or just because they want to. And I think we could rule out cases where the numbers aren't covered by a canonicalization mechanism understood by both ends. That might cover numbers that don't have E.164 representatons. But we *could* allow *some* of those to be covered by parameters to telephone-subscriber (such as phone-context). ISTM that STIR could cover any case not excluded by the above. Thanks, Paul > Regards > Andy > > > > >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Olle E. Johansson >> Sent: 26 June 2013 09:09 >> To: Michael Hammer >> Cc: stir@ietf.org; Olle E. Johansson; timothy.dwight@verizon.com; >> pkyzivat@alum.mit.edu >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >> >> >> 25 jun 2013 kl. 21:10 skrev Michael Hammer >> : >> >>> I think your last statement is the gist of this issue. >>> Is routing and authentication within a private network in scope for >> this >>> group. >>> I think not. >> >> I do agree. >> Now, the question is if the situation with two private networks >> peering using >> E.164 phone numbers is within scope? >> >> We will see more and more of that and the definition of "service >> provider" is less and less clear. >> >> There some sort of border we're looking for where a call using an >> E.164 number as a caller ID leaves a "domain" or "realm". >> >> /O >>> >>> Mike >>> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of >>> Dwight, Timothy M (Tim) >>> Sent: Tuesday, June 25, 2013 10:16 AM >>> To: Paul Kyzivat; stir@ietf.org >>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>> >>> It's not just an issue of what gets displayed. The PBX may have >> different >>> policies for internal and external calls. It's not necessarily the >> case >>> that every PBX in an Enterprise knows the E.164 numbers of every >> other PBX >>> in the Enterprise. That's why they have private dial plans... >>> >>> I won't comment on what works poorly or well, other than to note >>> that >> most >>> solutions can be made to fall into either category. >>> >>> This may all be moot if it's agreed to exclude calls that originate >> and >>> terminate within the same Enterprise, from this activity. >>> >>> Tim >>> >>> >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Paul >>> Kyzivat >>> Sent: Tuesday, June 25, 2013 12:05 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >>> >>> On 6/25/13 11:48 AM, Dwight, Timothy M (Tim) wrote: >>>> What about the private dial plan / sip trunking scenarios? In that >> case >>> it may be desired to deliver the FROM header in "non-canonical" >> format, so >>> that the recipient can know that this was an "internal" call. >>> >>> I have never understood this argument. >>> >>> If the call is "internal" (because the caller and callee are in the >> same >>> enterprise, regardless of whether the call transited a public hop), >> then the >>> recipient should be able to recognize that the From, in E.164 >>> format, >> is an >>> internal number. If it wants, the receiving device can apply the >> inverse of >>> the dial plan to the number to produce an internal dial string that >>> represents the caller, and display that as the caller id. >>> >>> I have experienced behavior such as you describe, that worked >>> poorly, because individual sites of the enterprise have different >>> dial plans, >> so >>> that the "local" number at one site has a different meaning when >> displayed >>> as caller id for the callee at a different site. >>> >>> If the calling number has no E.164 equivalent, then the telephone- >> subscriber >>> syntax used in both TEL and SIP has a phone-context param that can >>> be >> used >>> to represent the private number in a globally unique way. >>> >>> Thanks, >>> Paul >>> >>>> tim >>>> >>>> -----Original Message----- >>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>> Behalf Of Henning Schulzrinne >>>> Sent: Tuesday, June 25, 2013 10:13 AM >>>> To: philippe.fouquart@orange.com; Hadriel Kaplan >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the >>>> basics?) >>>> >>>> The signed entity would always be a full E.164 number, as the >>>> theory >> is >>> that both calling and called carrier are able to derive that >> canonical >>> format, as they need to do today for SS7 signaling, CNAM and >> intercarrier >>> compensation. Thus, the originating carrier would never sign >>> 212-555- >> 1212, >>> but only +12125551212. >>>> >>>> ________________________________________ >>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of >>>> philippe.fouquart@orange.com [philippe.fouquart@orange.com] >>>> Sent: Tuesday, June 25, 2013 8:49 AM >>>> To: Hadriel Kaplan >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the >> basics?) >>>> >>>> Hadriel, >>>> >>>> We seem to be talking past each other. I interpreted your comment >> as: >>>> a) the signing of the TN - who may be done directly or on behalf of >>>> the holder - may use a non canonical form of TN, >>>> b) supposing in-band, that signing would then be conveyed in some >> way >>>> yet TBD untouched to the verifier, and >>>> c) the verifier would then have to compute that "canonical form" to >>> eventually assert authenticity. >>>> >>>> My comment was that I didn't see how the verifier could reasonably >> do c) >>> without prior knowledge of the numbering plan of TN, so either the >> signer >>> and the verifier implicitly share the function according to which >>> you >> can >>> translate the non canonical form into a canonical form (eg they are >> on the >>> same dialing plan) or I don't see how this could work. Say >> TN=+12125551212, >>> but a) signs 2125551212 how could c) be correct unless the verifier >> knows >>> that it's an NANP number for which adding +1 upfront is enough to >> make it a >>> full E.164 number? >>>> >>>> What am I missing here? >>>> >>>> I definitely don't want to force anyone doing anything with the >> format of >>> their CLI, I was merely observing that, with the same examples, if >>> a) proceeds with 2125551212 and c) is not in the NANP number or >>> doesn't >> know >>> it's an NANP number, then I didn't see how it could determine what >>> canonicalization function to apply. >>>> >>>> Philippe Fouquart >>>> Orange Labs Networks >>>> +33 (0) 1 45 29 58 13 >>>> >>>> >>>> -----Original Message----- >>>> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >>>> Sent: Tuesday, June 25, 2013 8:00 AM >>>> To: FOUQUART Philippe OLNC/OLN >>>> Cc: Rosen, Brian; stir@ietf.org >>>> Subject: Re: [stir] URI formats (was RE: Do we agree on the >>>> basics?) >>>> >>>> >>>> On Jun 24, 2013, at 12:11 PM, philippe.fouquart@orange.com wrote: >>>>> I understand it may not be the priority here but as a target I >> think that >>> grand plan could remain in scope, and again, I think the extra >> flexibility >>> for a signer is quite minimal in most dialing plans and the added >> complexity >>> for the receiver is in my view not worth it. >>>> >>>> We could certainly have an RFC require the signing domain to >> generate a >>> To/From URI of E.164 and 'user=part' and all, but I don't see how >> that would >>> really succeed: >>>> >>>> 1) From a practical matter, legacy operators can't change all their >>> systems to suddenly use a new format; so you'd be forcing them to do >> the >>> signing function on their egress SBCs. While I expect that to be a >> common >>> scenario anyway, I don't think we'd want to force people to doing it >> there, >>> or on any SBCs for that matter. It should be possible to do the >> signing >>> anywhere on any system type, so long as the signing system knows the >> caller >>> can claim the E.164 number. >>>> >>>> 2) Even if the originator/signer does it that way, by the time the >>> terminating domain receives the call it will have come through >> transit >>> providers who already today change the To/From URIs. >>>> >>>> >>>>> Finally the irony of not providing a full canonical form is that >>>>> an increasing number of user data profiles contains the subscriber >>>>> number in its full E.164 format, so it may actually require *extra >>>>> work* to provide a different format in a CgP-related header. (I'm >> not >>>>> referring to R-Us which in the world I live in generally have to >>>>> be manipulated as some point to see the light of the CdP party's >>>>> endpoint or they'll just never get there - if this group were to >>>>> address such use cases, the logic may have to be different IMHO) >>>> >>>> Oh you don't have to provide it in a different format - if you >> provide it >>> in an E.164 format today you can continue to with STIR, and you can >> even >>> change from your current local format to using an E.164 format. We >> just >>> wouldn't be relying on everyone changing over, for STIR to work. >>>> >>>> -hadriel >>>> >>>> >>>> >>>> >> _____________________________________________________________________ >> _ >>>> ___________________________________________________ >>>> >>>> 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. >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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_006E_01CE724D.C15E3CF0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NjE2MTU1MlowIwYJKoZIhvcNAQkEMRYEFA11TyY4+OG92VfEhA8lXlavTj8AMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAQzWb+aFRxpQljysa0HMY+HA4xscUM3efkcI+vVoA cVUJUWppqp/wlDHMrJl8GtWrQ4SldBMLtLyNtp25DkmTbhomFHiJsELZsCvDexrdaT0sV1dKZErF hJqgd+P/TeEEitn64TqTLFr4O+LyNLNI1Oia4IhFXFN/edMwNWrMl+ysZc+AnSZPlMlgS9JJE+XF XEqRsS4eJc63vb4IUAwu05rsCikbNsda+JZIX5Emh7yM8AdWqBIOE/2l8AhqlMvVZyqObjg5cs6p uMblYFmvCS0R7dbOJuFYuZnO8ueMwv3Llcr7fGuZbXL6IfLH7oZcgCk6BX3U0rdS/xWiYtRHeAAA AAAAAA== ------=_NextPart_000_006E_01CE724D.C15E3CF0-- From Henning.Schulzrinne@fcc.gov Wed Jun 26 15:22: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 23AB021F9B12 for ; Wed, 26 Jun 2013 15:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 0QuiaHOK9abE for ; Wed, 26 Jun 2013 15:22:09 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1421F998D for ; Wed, 26 Jun 2013 15:22:08 -0700 (PDT) Message-ID: X-CheckPoint: {51CB698E-1000A-D2C987A5-1FFFF} From: Henning Schulzrinne To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMwgABZMACAAAL+AIAAIBoAgADZkICAAF9KAIAAA26AgABG3V8= Date: Wed, 26 Jun 2013 22:22:05 +0000 References: <13960_1371809055_51C4251F_13960_432_11_B5939C6860701C49AA39C5DA5189448B0A533B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> In-Reply-To: <51CAF483.9000305@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 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 22:22:14 -0000 +1. I would make one additional point, given that we're in chartering terri= tory: I suspect this is also an indicator of requirements cut-offs. In othe= r words, if supporting single-organization applications, such as the ones m= entioned by Paul, are causing complexity, such as arcane normalization rule= s, the need for special headers or the inability to normalize, in the inter= -organization case, I think that it's acceptable to defer those for later, = including "never". Since inter-organization calls already routinely have to= interface with systems (SS7, CNAM, billing, etc. that have been mentioned)= that are only marginally tolerant of random protocol and format variations= , that increases our chances of success and limits complexity.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu]=0A= Sent: Wednesday, June 26, 2013 10:02 AM=0A= To: stir@ietf.org=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= ISTM that we can consider out of scope cases where caller, callee, and=0A= the entire path are under control of a single organization (e.g., a=0A= business' private phone network). But they can still opt in for for=0A= regulatory reasons (e.g., a carrier) or just because they want to.=0A= =0A= And I think we could rule out cases where the numbers aren't covered by=0A= a canonicalization mechanism understood by both ends. That might cover=0A= numbers that don't have E.164 representatons. But we *could* allow=0A= *some* of those to be covered by parameters to telephone-subscriber=0A= (such as phone-context).=0A= =0A= ISTM that STIR could cover any case not excluded by the above.=0A= =0A= Thanks,=0A= Paul=0A= From dhc@dcrocker.net Wed Jun 26 15:33: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 C804521F9AC2 for ; Wed, 26 Jun 2013 15:33: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 wrJni3m96NLr for ; Wed, 26 Jun 2013 15:33:10 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA0A511E8112 for ; Wed, 26 Jun 2013 15:33:09 -0700 (PDT) Received: from [10.58.167.25] (72-254-8-40.client.stsn.net [72.254.8.40]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5QMX6Hx027168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Jun 2013 15:33:09 -0700 Message-ID: <51CB6C1C.4060303@dcrocker.net> Date: Wed, 26 Jun 2013 15:33:00 -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: "stir@ietf.org" References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@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, 26 Jun 2013 15:33:09 -0700 (PDT) Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) 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, 26 Jun 2013 22:33:15 -0000 I have an extremely naive suggestion. No doubt I'm entirely misunderstanding some range of basic, essential things. At the least, I hope that my suggestion prompts a concise summary of the this sub-topic in terms of the operational domain it will be applied to and the functional goal it must satisfy. The lengthy thread isn't all that easy to follow. So... As I understand the basic issue, the telephone number in the From field is not kept in a single, standardized form. At each stage of handling, the agent processing the message might coerce it to be any of a range of different forms. The details of why this is and how we might wish things otherwise are not helpful; the operational reality is what it is: numbers are represented in a variety of ways. However, the STIR verifier must have a canonical string to use for performing checking and the string needs to match the string that was used during signing. So here's my naive suggestion: For a message that is signed by the STIR mechanism, ignore whatever string is currently in the From field. Instead, take the canonical telephone number that is in the signature field -- I'm assuming that /it/ is /not/ messed with in transit -- and stuff it into the From field. In other word, use the STIR telephone number to override the string in the From field. Ok. start shooting... d/ On 6/26/2013 3:22 PM, Henning Schulzrinne wrote: > +1. I would make one additional point, given that we're in chartering territory: I suspect this is also an indicator of requirements cut-offs. In other words, if supporting single-organization applications, such as the ones mentioned by Paul, are causing complexity, such as arcane normalization rules, the need for special headers or the inability to normalize, in the inter-organization case, I think that it's acceptable to defer those for later, including "never". Since inter-organization calls already routinely have to interface with systems (SS7, CNAM, billing, etc. that have been mentioned) that are only marginally tolerant of random protocol and format variations, that increases our chances of success and limits complexity. > > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Wednesday, June 26, 2013 10:02 AM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > ISTM that we can consider out of scope cases where caller, callee, and > the entire path are under control of a single organization (e.g., a > business' private phone network). But they can still opt in for for > regulatory reasons (e.g., a carrier) or just because they want to. > > And I think we could rule out cases where the numbers aren't covered by > a canonicalization mechanism understood by both ends. That might cover > numbers that don't have E.164 representatons. But we *could* allow > *some* of those to be covered by parameters to telephone-subscriber > (such as phone-context). -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Wed Jun 26 16:07: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 C073211E8111 for ; Wed, 26 Jun 2013 16:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 WeOQTvQPafd7 for ; Wed, 26 Jun 2013 16:07:15 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 50A7A11E813B for ; Wed, 26 Jun 2013 16:07:14 -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 r5QN77Ux032338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 23:07: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 r5QN77EW013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 23:07:07 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5QN76Yq003733; Wed, 26 Jun 2013 23:07:06 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jun 2013 16:07:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51CB6C1C.4060303@dcrocker.net> Date: Wed, 26 Jun 2013 19:07:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@oracle.com> References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> <51CB6C1C.4060303@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 26 Jun 2013 23:07:21 -0000 It's not a naive suggestion - in fact it was considered several times = during debates about this topic in years past. :) We can't overwrite/replace the =46rom or To fields in the SIP message = with whatever this WG decides a canonical format is, because it will = break existing deployments. Obviously existing deployments have to = change slightly to perform STIR - namely they have to deploy a signer = and verifier - but only specific systems have to do that job and be = changed, and only in originating/terminating domains. In deployed SIP = use today, there are a lot of disparate systems in any given SIP domain, = and transit SIP domains in-between the originator+terminator. So since = we can't expect a flag-day to change everything, we have to leave the = To/=46rom alone. [one note on this is the transits will have to pass = along the new signature header, but that's a lot more likely to happen = than expecting them to change their numbering plans everywhere] There have also been suggestions for the signer to write the canonical = form into some new header(s) and have the verifier simply verify that = new header, but that idea is difficult too for a similar reason as above = but in a different way: since all the existing systems in the = terminating/verifying domain use the info in the =46rom (or PAI) as the = caller-id, then verifying some value in another header won't actually = prove anything about the caller-id that actually gets used for things. = In other words, since the voicemail, billing, CNAM, conf bridges, phone = displays, etc., use the =46rom for the caller-id, verifying something = else won't stop the bad guys from achieving their end goals unless we = change all those systems/phones to start using the new header for the = caller-id in a flag-day, which isn't reasonable.=20 -hadriel On Jun 26, 2013, at 6:33 PM, Dave Crocker wrote: > I have an extremely naive suggestion. No doubt I'm entirely = misunderstanding some range of basic, essential things. >=20 > At the least, I hope that my suggestion prompts a concise summary of = the this sub-topic in terms of the operational domain it will be applied = to and the functional goal it must satisfy. The lengthy thread isn't = all that easy to follow. >=20 > So... >=20 > As I understand the basic issue, the telephone number in the =46rom = field is not kept in a single, standardized form. At each stage of = handling, the agent processing the message might coerce it to be any of = a range of different forms. The details of why this is and how we might = wish things otherwise are not helpful; the operational reality is what = it is: numbers are represented in a variety of ways. >=20 > However, the STIR verifier must have a canonical string to use for = performing checking and the string needs to match the string that was = used during signing. >=20 > So here's my naive suggestion: >=20 > For a message that is signed by the STIR mechanism, ignore whatever = string is currently in the =46rom field. >=20 > Instead, take the canonical telephone number that is in the = signature field -- I'm assuming that /it/ is /not/ messed with in = transit -- and stuff it into the =46rom field. >=20 > In other word, use the STIR telephone number to override the string = in the =46rom field. >=20 >=20 > Ok. start shooting... >=20 > d/ >=20 From michael.hammer@yaanatech.com Wed Jun 26 18:39: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 4E55D11E817F for ; Wed, 26 Jun 2013 18:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 FlHja4oOM6n2 for ; Wed, 26 Jun 2013 18:39: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 3774D11E815C for ; Wed, 26 Jun 2013 18:39:33 -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, 26 Jun 2013 18:39:32 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "dcrocker@bbiw.net" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXA= Date: Thu, 27 Jun 2013 01:39:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0DE60@EX2K10MB1.corp.yaanatech.com> References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> <51CB6C1C.4060303@dcrocker.net> <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@oracle.com> In-Reply-To: <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01CD_01CE729C.7F6A7170" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 01:39:37 -0000 ------=_NextPart_000_01CD_01CE729C.7F6A7170 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So, do you want to keep your cake whole or eat it? You cannot have both a canonical value that can be relied on and maximum flexibility to mangle the From header. Something has to give. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Wednesday, June 26, 2013 4:07 PM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) It's not a naive suggestion - in fact it was considered several times during debates about this topic in years past. :) We can't overwrite/replace the From or To fields in the SIP message with whatever this WG decides a canonical format is, because it will break existing deployments. Obviously existing deployments have to change slightly to perform STIR - namely they have to deploy a signer and verifier - but only specific systems have to do that job and be changed, and only in originating/terminating domains. In deployed SIP use today, there are a lot of disparate systems in any given SIP domain, and transit SIP domains in-between the originator+terminator. So since we can't expect a flag-day to change everything, we have to leave the To/From alone. [one note on this is the transits will have to pass along the new signature header, but that's a lot more likely to happen than expecting them to change their numbering plans everywhere] There have also been suggestions for the signer to write the canonical form into some new header(s) and have the verifier simply verify that new header, but that idea is difficult too for a similar reason as above but in a different way: since all the existing systems in the terminating/verifying domain use the info in the From (or PAI) as the caller-id, then verifying some value in another header won't actually prove anything about the caller-id that actually gets used for things. In other words, since the voicemail, billing, CNAM, conf bridges, phone displays, etc., use the From for the caller-id, verifying something else won't stop the bad guys from achieving their end goals unless we change all those systems/phones to start using the new header for the caller-id in a flag-day, which isn't reasonable. -hadriel On Jun 26, 2013, at 6:33 PM, Dave Crocker wrote: > I have an extremely naive suggestion. No doubt I'm entirely misunderstanding some range of basic, essential things. > > At the least, I hope that my suggestion prompts a concise summary of the this sub-topic in terms of the operational domain it will be applied to and the functional goal it must satisfy. The lengthy thread isn't all that easy to follow. > > So... > > As I understand the basic issue, the telephone number in the From field is not kept in a single, standardized form. At each stage of handling, the agent processing the message might coerce it to be any of a range of different forms. The details of why this is and how we might wish things otherwise are not helpful; the operational reality is what it is: numbers are represented in a variety of ways. > > However, the STIR verifier must have a canonical string to use for performing checking and the string needs to match the string that was used during signing. > > So here's my naive suggestion: > > For a message that is signed by the STIR mechanism, ignore whatever string is currently in the From field. > > Instead, take the canonical telephone number that is in the signature field -- I'm assuming that /it/ is /not/ messed with in transit -- and stuff it into the From field. > > In other word, use the STIR telephone number to override the string in the From field. > > > Ok. start shooting... > > d/ > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_01CD_01CE729C.7F6A7170 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NzAxMzkzMVowIwYJKoZIhvcNAQkEMRYEFNzaWL907GAsbGWRegx/Fs+NTNfRMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAPLnPNWvcrvzZgjWGXIGdK53BoVrQHp9j34oGLb6E HAPp8Wt5SaNRm7YTKP23DpnYo5rl6f5y0kyWSYJ3PcJuQCs6uDO+4mk52vvXbuUp4Q6V/AGCBTRC V3iEv76t/AdYKE2TTW5kG/iHUf7iIPSe9i7EhFMg8T5vhmlJ3b9A+izLtiQzjPRKyadQr9Ug9m8K wmYxWT5DYHe25azvngNP6v2KEX7UXFHszHxN0gW8hcX0tN4ZwsDRS0I/0/bZ3y/yNKrwYWvtOmEI BhQOvNGyhEGviGhXob+w0AW8w7YMUtm397BDDYY6reCaD8FArgUJ8myhnwrjqXBePo+IORvkawAA AAAAAA== ------=_NextPart_000_01CD_01CE729C.7F6A7170-- From hadriel.kaplan@oracle.com Wed Jun 26 21:30: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 C8A6811E81F3 for ; Wed, 26 Jun 2013 21:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, 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 fvmWnDy8MJnj for ; Wed, 26 Jun 2013 21:30:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 423F111E8105 for ; Wed, 26 Jun 2013 21:30:47 -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 r5R4Ufuh019016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 04:30:42 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 r5R4UdDS026539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 04:30:40 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 r5R4UdjH027096; Thu, 27 Jun 2013 04:30:39 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-172-161.vpn.oracle.com (/10.154.172.161) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jun 2013 21:30: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: <00C069FD01E0324C9FFCADF539701DB3BBC0DE60@EX2K10MB1.corp.yaanatech.com> Date: Thu, 27 Jun 2013 00:30:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2854CFE3-C95B-431E-BACE-4CC55B5DBF5B@oracle.com> References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> <51CB6C1C.4060303@dcrocker.net> <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@! oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0DE60@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 04:30:53 -0000 On Jun 26, 2013, at 9:39 PM, Michael Hammer = wrote: > So, do you want to keep your cake whole or eat it? Welll... based on my physical weight I'd say I always eat the cake, and = ask for seconds. :) > You cannot have both a canonical value that can be relied on and = maximum > flexibility to mangle the =46rom header. > Something has to give. The premise so far has been that you can do both - you can mangle the = =46rom header in the message all you like, so long as you can figure out = what the From's E.164 number would be. And I'd argue there's plenty of = evidence that is the case: that regardless of the syntax used in the = encoding, the originator and terminator domains both know what the = 'real' E.164 is for a given URI (assuming it's an E.164 at all), because = if they didn't then all kinds of things wouldn't work right today. But let's play devil's advocate. Let's say the premise is wrong: that = in fact originators use syntax X and terminators use syntax Y and the = terminator can't correctly figure out what the From's E.164 is today. = What could we do about it and why would we need to? After all, if the = terminating domain can't figure out what the =46rom E.164 number is = today, then in what way is the =46rom being used such that we need to = validate them as E.164 numbers for such a terminating domain? I.e., if = they're not using the =46rom for a source identity, then what's broken = for them that we need to fix? And if they're not using them as E.164's, = then why would they care to change their behavior for a STIR RFC? [note: I say "E.164" but really I mean a phone-number: something that = either is an E.164 or can be converted to such, for example by = prepending a country-code and an area-code] -hadriel From dhc@dcrocker.net Thu Jun 27 07:40: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 72A6221F9E65 for ; Thu, 27 Jun 2013 07:40:37 -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 jSqVoWTV2S1V for ; Thu, 27 Jun 2013 07:40:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF42D21F9814 for ; Thu, 27 Jun 2013 07:40:32 -0700 (PDT) Received: from [10.58.166.202] (72-254-41-211.client.stsn.net [72.254.41.211]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5REeSQp014553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 Jun 2013 07:40:31 -0700 Message-ID: <51CC4ED6.30408@dcrocker.net> Date: Thu, 27 Jun 2013 07:40:22 -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: "stir@ietf.org" Content-Type: text/plain; charset=windows-1252; 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, 27 Jun 2013 07:40:32 -0700 (PDT) Subject: [stir] Revised charter text for 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: Thu, 27 Jun 2013 14:40:37 -0000 Folks, Based on the apparent trend on the list to favor a narrower working group charter, as well as the rest of what has been discussed on the list, here is revised draft charter text to consider. It focuses on specification of an authorization validation method and a method for getting the information needed to perform validation. The example of the first is signature in an identity field. The example of the latter is a query to an external database, to get keys, credentials or the like. But the language is intentionally non-technical, in order to leave the technical choices to the working group. Hence, for example, it does not attempt to resolve the choice between "credential" or "public key", nor HTTP vs. DNS. It removes details that are not essential to the work and that might invite irrelevant debate. The first paragraph is designed to stand alone as a summary abstract; this is actually a formal requirement for charter text, since the first paragraph is what's circulated in announcements. d/ Name: Secure Telephone Identity Revisited (stir) Area: RAI Chairs: TBD Area Advisor: TBD (Barnes) Mailing list: https://www.ietf.org/mailman/listinfo/stir To Subscribe: -- As with email, the claimed source identity of a SIP request (in the From field) is not verified. As with email, this permits and produces unauthorized use of source identities as part of deceptive and coercive activities, such as bulk unsolicited commercial communications, voicemail hacking, and impersonating banks. The current effort will specify a mechanism to support validation that a telephone number's presence in the SIP From field is authorized by the entity formally assigned use of that number, or by their delegate. The mechanism will support end-to-end SIP interactions. Initial specification will be in terms of a pure-SIP exchange, which will serve as the operational base. Additional mechanisms might later be developed to support more complicated mediation scenarios. The working group will consider choices for the method of specifying authorization information and the means of obtaining the parametric information needed to perform that authorization check. An example of the first could be use of a cryptographically-protected field carried by SIP and containing identity and authentication information. An example of the second could be a mechanism for querying an external database, to obtain the key-signing parameters for the authentication cryptography. A number of previous efforts have attacked the problem of securing the origins of SIP communications, including RFC3325, RFC4474 and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. While several factors contributed to this lack of success, culprits included: failure of the problem to be seen as critical at the time; lack of any real means of asserting authority over telephone numbers on the Internet; misalignment of the mechanisms proposed by RFC4474 with the complex deployment environment that has emerged for SIP; and inherent operational problems with a transitive trust model. 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 http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 Secure Origin Identification: Problem Statement, Requirements, and Roadmap http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 Authenticated Identity Management in the Session Initiation Protocol (SIP) http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 A likely approach for SIP-based authorization validation is to include a new capability for Identity assertions to cover telephone numbers, rather than domain names. To conform with realistic deployments. The working group will coordinate with the security area, for any proposal details that utilize classic security mechanisms, such as cryptography and certificate credentials. The working group will coordinate with RAI area groups studying the problem of signaling through existing deployments, including activities in the INSIPID and STRAW working groups. Identity is closely linked to privacy, and frequently one comes at the cost of the other. To the extent feasible the working group will favor privacy-friendly choices that minimize call information leakage to third parties. The working group will deliver the following: - Problem statement detailing the deployment environment and difficulties motivating work on secure origins - Specification of an authorization validation method for the source telephone number identity of a SIP request (in the From field) - Specification of the means for obtaining security-related parametric information, used to perform source telephone number identity authorization validation. Milestones Sep 2013 Submit problem statement for Info Dec 2013 Submit STIR authorization validation method for PS Mar 2013 Submit STIR parametric information draft for PS -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Thu Jun 27 08:51: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 8CBC321F9E02 for ; Thu, 27 Jun 2013 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vayfca1CpbWl for ; Thu, 27 Jun 2013 08:51: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 3408621F9DF4 for ; Thu, 27 Jun 2013 08:51: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; Thu, 27 Jun 2013 08:51:32 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+Wg Date: Thu, 27 Jun 2013 15:51:31 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0DFF8@EX2K10MB1.corp.yaanatech.com> References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> <51CB6C1C.4060303@dcrocker.net> <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@! oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0DE60@EX2K10MB1.corp.yaanatech.com> <2854CFE3-C95B-431E-BACE-4CC55B5DBF5B@oracle.com> In-Reply-To: <2854CFE3-C95B-431E-BACE-4CC55B5DBF5B@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01CE7313.84C726A0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 15:51:45 -0000 ------=_NextPart_000_0005_01CE7313.84C726A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You've just made the argument that the STIR WG is not needed. Guess we can all go home now. :) You've essentially said that we must trust whatever the latest network mangles the From header to be and assume to trust that network. I've been trying to discover in all the suggestions how that chain of trust is preserved from the start. But, you argue against any E2E trust, just hop-by-hop. That doesn't seem to be working so well today. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Wednesday, June 26, 2013 9:31 PM To: Michael Hammer Cc: dcrocker@bbiw.net; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) On Jun 26, 2013, at 9:39 PM, Michael Hammer wrote: > So, do you want to keep your cake whole or eat it? Welll... based on my physical weight I'd say I always eat the cake, and ask for seconds. :) > You cannot have both a canonical value that can be relied on and > maximum flexibility to mangle the From header. > Something has to give. The premise so far has been that you can do both - you can mangle the From header in the message all you like, so long as you can figure out what the From's E.164 number would be. And I'd argue there's plenty of evidence that is the case: that regardless of the syntax used in the encoding, the originator and terminator domains both know what the 'real' E.164 is for a given URI (assuming it's an E.164 at all), because if they didn't then all kinds of things wouldn't work right today. But let's play devil's advocate. Let's say the premise is wrong: that in fact originators use syntax X and terminators use syntax Y and the terminator can't correctly figure out what the From's E.164 is today. What could we do about it and why would we need to? After all, if the terminating domain can't figure out what the From E.164 number is today, then in what way is the From being used such that we need to validate them as E.164 numbers for such a terminating domain? I.e., if they're not using the From for a source identity, then what's broken for them that we need to fix? And if they're not using them as E.164's, then why would they care to change their behavior for a STIR RFC? [note: I say "E.164" but really I mean a phone-number: something that either is an E.164 or can be converted to such, for example by prepending a country-code and an area-code] -hadriel ------=_NextPart_000_0005_01CE7313.84C726A0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NzE1NTEzMFowIwYJKoZIhvcNAQkEMRYEFNzPOub2nVkG718lj196EQrBPCGrMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAL+F3Kb/9tqRWYXQ3UnxG8uREkuzfxWg5SHvw5ZVl qJjfW8LEVOnVLOqzN7CClOxqrl2GkCJXBieC8xdbc3nwmIuOBeCiGGyqTXqiLCYBsazTc4Cc4aey plubjdb6QFKtpSXClGFV0WFlPbzBTqBkIyHjWowYC5m8LW6T4H7ICVGPb+/RuLizesJwIoVqAa7Z dx7ZPdLJfCo1+8mRYDEb4pPIwXZ/n7bxLw0ufcx4c/3cf27cH6pDUud4aGrfDCXGRDKnQt9GG9op ihzRi/ZFR9seOU7TWoeM8VMDFjyEYr91XqMYYh5607I6af/iTRGBDmw7I9AYAd2LTqGnw9eiXgAA AAAAAA== ------=_NextPart_000_0005_01CE7313.84C726A0-- From hadriel.kaplan@oracle.com Thu Jun 27 09:42: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 982B321F9993 for ; Thu, 27 Jun 2013 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 WHrXccKd-Vur for ; Thu, 27 Jun 2013 09:42:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0721F9E58 for ; Thu, 27 Jun 2013 09:42:18 -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 r5RGgCiT012664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 16:42:13 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 r5RGgBwf024486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 16:42:11 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 r5RGgBOq024468; Thu, 27 Jun 2013 16:42:11 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 09:42: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: <00C069FD01E0324C9FFCADF539701DB3BBC0DFF8@EX2K10MB1.corp.yaanatech.com> Date: Thu, 27 Jun 2013 12:42:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31141_1372090302_51C86FBE_31141_12_1_B5939C6860701C49AA39C5DA5189448B0A57D9@PEXCVZYM12.corporate.adroot.infra.ftgroup> <91C8C970-C294-4B30-AEE9-E2ADAE6F6E0A@oracle.com>, <28626_1372164599_51C991F7_28626_6377_1_B5939C6860701C49AA39C5DA5189448B0A5A1B@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2B0F677F0B95454297753F58D4A07FA30127E3DFC9@FHDP1LUMXC7V31.us.one.verizon.com> <51C9CDC2.80106@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA30127E3E0C1@FHDP1LUMXC7V31.us.one.verizon.com> <0 0C069FD01E0324C9FFCADF539701DB3BBC0C4D4@EX2K10MB1.corp.yaanatech.com> <21927135-7E44-4694-A3AA-6680793A08B5@edvina.net> <9F33F40F6F2CD847824537F3C4E37DDF115DA21A@MCHP04MSX.global-ad.net>, <51CAF483.9000305@alum.mit.edu> <51CB6C1C.4060303@dcrocker.net> <9453FCA5-CA6C-4E99-A32B-F554275CB2BA@! ! oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0DE60@EX2K10MB1.corp.yaanatech.com> <2854CFE3-C95B-431E-BACE-4CC55B5DBF5B@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0DFF8@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 16:42:30 -0000 On Jun 27, 2013, at 11:51 AM, Michael Hammer = wrote: > You've just made the argument that the STIR WG is not needed. > Guess we can all go home now. :) >=20 > You've essentially said that we must trust whatever the latest network > mangles the =46rom header to be and assume to trust that network. > I've been trying to discover in all the suggestions how that chain of = trust > is preserved from the start. > But, you argue against any E2E trust, just hop-by-hop. > That doesn't seem to be working so well today. I don't think I've done that - how have I done it? I haven't said you have to trust the =46rom - I said the =46rom can and = will be changed in syntax/format. Ultimately the guy receiving and = using the caller-id (the E.164 number) needs to know it's a valid = *phone-number* - what he does *not* need to know is that the =46rom URI = string encoding has been unchanged. This whole exercise is about = preventing spoofed E.164 caller-ids - not about preventing a =46rom = header field string as opaque data. It does not matter if it started as 'sip:5551212@aaa.com;user=3Dphone' = and got received as 'sip:+1-212-555-1212@bbb.com'; because if the = terminator uses it as the E.164 phone number '12125551212' in his = systems and caller-id displays, then what he really needs to know is = that this call request came from someone with the authority to claim = '12125551212' - he does *not* need to know it really came from = 'bbb.com', nor that it came from user '+1-212-555-1212', nor even that = it came from SIP. There is nothing anyone in the middle can do to successfully break this = - no amount of their header munging will succeed, because if they change = the actual number to be interpreted by the terminator as something else, = like '161712345678' instead, then the signature will fail as it should = fail. If they munge the headers so it can't be interpreted as any E.164 = phone number, then the signature fails as it should fail. If they munge = the headers so that it's still interpreted as '12125551212', then they = haven't succeeded in spoofing anyone. I recognize this won't protect = the rest of the =46rom URI - but that's not the goal. The goal is to = prevent spoofing Caller-IDs. Nothing more. -hadriel From hadriel.kaplan@oracle.com Thu Jun 27 09: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 3028421F9E30 for ; Thu, 27 Jun 2013 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, 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 oQ7kqQPi8bAq for ; Thu, 27 Jun 2013 09:51:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D447A21F9E28 for ; Thu, 27 Jun 2013 09:51:03 -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 r5RGidJZ009237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 16:44: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 r5RGovB9020053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 16:50:58 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 r5RGovle027697; Thu, 27 Jun 2013 16:50:57 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 09:50:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51CC4ED6.30408@dcrocker.net> Date: Thu, 27 Jun 2013 12:50:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CC4ED6.30408@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 16:51:09 -0000 I like this charter much more - I think it avoids the contentious = aspects that could drag down the BOF, while at the same time narrows the = scope of initial work to do. I have one nit-pick though: I don't think it should list/mention the = individual drafts as "input" to the WG. Listing the RFCs makes sense, = but the individual drafts are just individual drafts, and there are a = lot more that have been submitted over the years that we could dredge up = as input. Is it meant as just a reading list type thing for background? = Do we put that in charters typically? -hadriel On Jun 27, 2013, at 10:40 AM, Dave Crocker wrote: > Folks, >=20 > Based on the apparent trend on the list to favor a narrower working = group charter, as well as the rest of what has been discussed on the = list, here is revised draft charter text to consider. >=20 > It focuses on specification of an authorization validation method and = a method for getting the information needed to perform validation. The = example of the first is signature in an identity field. The example of = the latter is a query to an external database, to get keys, credentials = or the like. But the language is intentionally non-technical, in order = to leave the technical choices to the working group. Hence, for = example, it does not attempt to resolve the choice between "credential" = or "public key", nor HTTP vs. DNS. >=20 > It removes details that are not essential to the work and that might = invite irrelevant debate. >=20 > The first paragraph is designed to stand alone as a summary abstract; = this is actually a formal requirement for charter text, since the first = paragraph is what's circulated in announcements. >=20 >=20 > d/ >=20 >=20 >=20 >=20 > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: TBD (Barnes) >=20 > Mailing list: https://www.ietf.org/mailman/listinfo/stir > To Subscribe: -- >=20 >=20 > As with email, the claimed source identity of a SIP request (in the = From > field) is not verified. As with email, this permits and produces > unauthorized use of source identities as part of deceptive and = coercive > activities, such as bulk unsolicited commercial communications, > voicemail hacking, and impersonating banks. The current effort will > specify a mechanism to support validation that a telephone number's > presence in the SIP =46rom field is authorized by the entity formally > assigned use of that number, or by their delegate. The mechanism will > support end-to-end SIP interactions. Initial specification will be in > terms of a pure-SIP exchange, which will serve as the operational = base. > Additional mechanisms might later be developed to support more > complicated mediation scenarios. >=20 > The working group will consider choices for the method of specifying > authorization information and the means of obtaining the parametric > information needed to perform that authorization check. An example of > the first could be use of a cryptographically-protected field carried = by > SIP and containing identity and authentication information. An example > of the second could be a mechanism for querying an external database, = to > obtain the key-signing parameters for the authentication cryptography. >=20 > A number of previous efforts have attacked the problem of securing the > origins of SIP communications, including RFC3325, RFC4474 and the VIPR > working group. To date, however, true validation of the source of SIP > calls has not seen any appreciable deployment. While several factors > contributed to this lack of success, culprits included: failure of the > problem to be seen as critical at the time; lack of any real means of > asserting authority over telephone numbers on the Internet; = misalignment > of the mechanisms proposed by RFC4474 with the complex deployment > environment that has emerged for SIP; and inherent operational = problems > with a transitive trust model. >=20 >=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 > http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >=20 > Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >=20 > Authenticated Identity Management in the Session Initiation > Protocol (SIP) > http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 >=20 > A likely approach for SIP-based authorization validation is to include = a > new capability for Identity assertions to cover telephone numbers, > rather than domain names. To conform with realistic deployments. >=20 > The working group will coordinate with the security area, for any > proposal details that utilize classic security mechanisms, such as > cryptography and certificate credentials. >=20 > The working group will coordinate with RAI area groups studying the > problem of signaling through existing deployments, including = activities > in the INSIPID and STRAW working groups. >=20 > Identity is closely linked to privacy, and frequently one comes at the > cost of the other. To the extent feasible the working group will favor > privacy-friendly choices that minimize call information leakage to = third > parties. >=20 > The working group will deliver the following: >=20 > - Problem statement detailing the deployment environment and > difficulties motivating work on secure origins >=20 > - Specification of an authorization validation method for the source > telephone number identity of a SIP request (in the From > field) >=20 > - Specification of the means for obtaining security-related parametric > information, used to perform source telephone number identity > authorization validation. >=20 >=20 > Milestones >=20 > Sep 2013 Submit problem statement for Info > Dec 2013 Submit STIR authorization validation method for PS > Mar 2013 Submit STIR parametric information draft for PS >=20 >=20 >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From adam.uzelac@gmail.com Thu Jun 27 10:48: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 27B2E21F9E47 for ; Thu, 27 Jun 2013 10:48:25 -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, HTML_MESSAGE=0.001, NO_RELAYS=-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 DyGrb5VQMoBk for ; Thu, 27 Jun 2013 10:48:23 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B521F9A7E for ; Thu, 27 Jun 2013 10:48:23 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so1213537pbc.26 for ; Thu, 27 Jun 2013 10:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=a+E3zsQBDE/hPsRpOfBrDaN+aspiw90srT+bQfGUpCM=; b=MyT6HuMClXeGzUTSTyPcqj5q+CoKWdVciS/Hyk+l21SGWoDvuKA7M1/EJNV+jG5dTX /+EhqXG0e1Xb9r5ePuucdCu/dOjjx5creYhFsHdDcY8fYA7R+y+LWHNFAqlfxgQxwmKB 1IkKv0T4VEHwG7cvAJswgxkz6Kk7RHvg30Pc1ToLAmcSnfQvHBs4Dv3v6RVWAlgErHYO qtccFIid/KnezvVnK+fpYbYo5bae8kvTYMB7LMfK/STibaly8H70AU5RRexCozdIca7k W/azZqzvcsYylykVm0Jgb9SOwHriEC1UR4B2T92NPhKS20ukjT2F49NqnANSOaEy+qnJ yrEg== MIME-Version: 1.0 X-Received: by 10.66.122.131 with SMTP id ls3mr7164476pab.2.1372355303452; Thu, 27 Jun 2013 10:48:23 -0700 (PDT) Sender: voiploser@gmail.com X-Google-Sender-Delegation: voiploser@gmail.com Received: by 10.67.5.163 with HTTP; Thu, 27 Jun 2013 10:48:23 -0700 (PDT) In-Reply-To: References: <51CC4ED6.30408@dcrocker.net> Date: Thu, 27 Jun 2013 13:48:23 -0400 X-Google-Sender-Auth: YYN6jArMoGei6XBK0QFiFVVQt48 Message-ID: From: Adam Uzelac To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7bf0e0525e3d6d04e0265e2f Cc: "stir@ietf.org" , dcrocker@bbiw.net Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 17:48:25 -0000 --047d7bf0e0525e3d6d04e0265e2f Content-Type: text/plain; charset=ISO-8859-1 I have to agree with Hadriel that listing the drafts probably isn't a good idea. You're bound to leave some out (I am thinking of draft-kuthan-sip-derive - which has merit, but that's not the point, so ignore). Also - fwiw, I think the timing of this is effort is better this time around. -Adam On Thu, Jun 27, 2013 at 12:50 PM, Hadriel Kaplan wrote: > > I like this charter much more - I think it avoids the contentious aspects > that could drag down the BOF, while at the same time narrows the scope of > initial work to do. > > I have one nit-pick though: I don't think it should list/mention the > individual drafts as "input" to the WG. Listing the RFCs makes sense, but > the individual drafts are just individual drafts, and there are a lot more > that have been submitted over the years that we could dredge up as input. > Is it meant as just a reading list type thing for background? Do we put > that in charters typically? > > -hadriel > > > On Jun 27, 2013, at 10:40 AM, Dave Crocker wrote: > > > Folks, > > > > Based on the apparent trend on the list to favor a narrower working > group charter, as well as the rest of what has been discussed on the list, > here is revised draft charter text to consider. > > > > It focuses on specification of an authorization validation method and a > method for getting the information needed to perform validation. The > example of the first is signature in an identity field. The example of the > latter is a query to an external database, to get keys, credentials or the > like. But the language is intentionally non-technical, in order to leave > the technical choices to the working group. Hence, for example, it does > not attempt to resolve the choice between "credential" or "public key", nor > HTTP vs. DNS. > > > > It removes details that are not essential to the work and that might > invite irrelevant debate. > > > > The first paragraph is designed to stand alone as a summary abstract; > this is actually a formal requirement for charter text, since the first > paragraph is what's circulated in announcements. > > > > > > d/ > > > > > > > > > > Name: Secure Telephone Identity Revisited (stir) > > Area: RAI > > > > Chairs: TBD > > Area Advisor: TBD (Barnes) > > > > Mailing list: https://www.ietf.org/mailman/listinfo/stir > > To Subscribe: -- > > > > > > As with email, the claimed source identity of a SIP request (in the From > > field) is not verified. As with email, this permits and produces > > unauthorized use of source identities as part of deceptive and coercive > > activities, such as bulk unsolicited commercial communications, > > voicemail hacking, and impersonating banks. The current effort will > > specify a mechanism to support validation that a telephone number's > > presence in the SIP From field is authorized by the entity formally > > assigned use of that number, or by their delegate. The mechanism will > > support end-to-end SIP interactions. Initial specification will be in > > terms of a pure-SIP exchange, which will serve as the operational base. > > Additional mechanisms might later be developed to support more > > complicated mediation scenarios. > > > > The working group will consider choices for the method of specifying > > authorization information and the means of obtaining the parametric > > information needed to perform that authorization check. An example of > > the first could be use of a cryptographically-protected field carried by > > SIP and containing identity and authentication information. An example > > of the second could be a mechanism for querying an external database, to > > obtain the key-signing parameters for the authentication cryptography. > > > > A number of previous efforts have attacked the problem of securing the > > origins of SIP communications, including RFC3325, RFC4474 and the VIPR > > working group. To date, however, true validation of the source of SIP > > calls has not seen any appreciable deployment. While several factors > > contributed to this lack of success, culprits included: failure of the > > problem to be seen as critical at the time; lack of any real means of > > asserting authority over telephone numbers on the Internet; misalignment > > of the mechanisms proposed by RFC4474 with the complex deployment > > environment that has emerged for SIP; and inherent operational problems > > with a transitive trust model. > > > > > > 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 > > http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 > > > > Secure Origin Identification: Problem Statement, Requirements, > > and Roadmap > > http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 > > > > Authenticated Identity Management in the Session Initiation > > Protocol (SIP) > > http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 > > > > A likely approach for SIP-based authorization validation is to include a > > new capability for Identity assertions to cover telephone numbers, > > rather than domain names. To conform with realistic deployments. > > > > The working group will coordinate with the security area, for any > > proposal details that utilize classic security mechanisms, such as > > cryptography and certificate credentials. > > > > The working group will coordinate with RAI area groups studying the > > problem of signaling through existing deployments, including activities > > in the INSIPID and STRAW working groups. > > > > Identity is closely linked to privacy, and frequently one comes at the > > cost of the other. To the extent feasible the working group will favor > > privacy-friendly choices that minimize call information leakage to third > > parties. > > > > The working group will deliver the following: > > > > - Problem statement detailing the deployment environment and > > difficulties motivating work on secure origins > > > > - Specification of an authorization validation method for the source > > telephone number identity of a SIP request (in the From > > field) > > > > - Specification of the means for obtaining security-related parametric > > information, used to perform source telephone number identity > > authorization validation. > > > > > > Milestones > > > > Sep 2013 Submit problem statement for Info > > Dec 2013 Submit STIR authorization validation method for PS > > Mar 2013 Submit STIR parametric information draft for PS > > > > > > > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > -- > > 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 > --047d7bf0e0525e3d6d04e0265e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have to agree with Hadriel that listing the drafts proba= bly isn't a good idea. =A0You're bound to leave some out (I am thin= king of draft-kuthan-sip-derive - which has merit, but that's not the p= oint, so ignore). =A0

Also - fwiw, I think the timing of this is effort is better = this time around. =A0

-Adam


On Thu, Jun 27, 20= 13 at 12:50 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com><= /span> wrote:

I like this charter much more - I think it avoids the contentious aspects t= hat could drag down the BOF, while at the same time narrows the scope of in= itial work to do.

I have one nit-pick though: I don't think it should list/mention the in= dividual drafts as "input" to the WG. =A0Listing the RFCs makes s= ense, but the individual drafts are just individual drafts, and there are a= lot more that have been submitted over the years that we could dredge up a= s input. =A0Is it meant as just a reading list type thing for background? = =A0Do we put that in charters typically?

-hadriel


On Jun 27, 2013, at 10:40 AM, Dave Crocker <dhc@dcrocker.net> wrote:

> Folks,
>
> Based on the apparent trend on the list to favor a narrower working gr= oup charter, as well as the rest of what has been discussed on the list, he= re is revised draft charter text to consider.
>
> It focuses on specification of an authorization validation method and = a method for getting the information needed to perform validation. =A0The e= xample of the first is signature in an identity field. =A0The example of th= e latter is a query to an external database, to get keys, credentials or th= e like. =A0But the language is intentionally non-technical, in order to lea= ve the technical choices to the working group. =A0Hence, for example, it do= es not attempt to resolve the choice between "credential" or &quo= t;public key", nor HTTP vs. DNS.
>
> It removes details that are not essential to the work and that might i= nvite irrelevant debate.
>
> The first paragraph is designed to stand alone as a summary abstract; = this is actually a formal requirement for charter text, since the first par= agraph is what's circulated in announcements.
>
>
> d/
>
>
>
>
> Name: Secure Telephone Identity Revisited (stir)
> Area: RAI
>
> Chairs: TBD
> Area Advisor: TBD (Barnes)
>
> Mailing list: https://www.ietf.org/mailman/listinfo/stir
> To Subscribe: --
>
>
> As with email, the claimed source identity of a SIP request (in the Fr= om
> field) is not verified. As with email, this permits and produces
> unauthorized use of source identities as part of deceptive and coerciv= e
> activities, such as bulk unsolicited commercial communications,
> voicemail hacking, and impersonating banks. The current effort will > specify a mechanism to support validation that a telephone number'= s
> presence in the SIP From field is authorized by the entity formally > assigned use of that number, or by their delegate. The mechanism will<= br> > support end-to-end SIP interactions. Initial specification will be in<= br> > terms of a pure-SIP exchange, which will serve as the operational base= .
> Additional mechanisms might later be developed to support more
> complicated mediation scenarios.
>
> The working group will consider choices for the method of specifying > authorization information and the means of obtaining the parametric > information needed to perform that authorization check. An example of<= br> > the first could be use of a cryptographically-protected field carried = by
> SIP and containing identity and authentication information. An example=
> of the second could be a mechanism for querying an external database, = to
> obtain the key-signing parameters for the authentication cryptography.=
>
> A number of previous efforts have attacked the problem of securing the=
> origins of SIP communications, including RFC3325, RFC4474 and the VIPR=
> working group. To date, however, true validation of the source of SIP<= br> > calls has not seen any appreciable deployment. While several factors > contributed to this lack of success, culprits included: failure of the=
> problem to be seen as critical at the time; lack of any real means of<= br> > asserting authority over telephone numbers on the Internet; misalignme= nt
> of the mechanisms proposed by RFC4474 with the complex deployment
> environment that has emerged for SIP; and inherent operational problem= s
> with a transitive trust model.
>
>
> Input to working group discussions shall include:
>
> =A0 Private Extensions to the Session Initiation Protocol (SIP)
> =A0 for Asserted Identity within Trusted Networks
> =A0 RFC 3325
>
> =A0 Enhancements for Authenticated Identity Management in the
> =A0 Session Initiation Protocol (SIP)
> =A0 RFC 4474
>
> =A0 Secure Call Origin Identification
> =A0 http://tools.ietf.org/html/draft-cooper-iab-secure= -origin-00
>
> =A0 Secure Origin Identification: Problem Statement, Requirements,
> =A0 and Roadmap
> =A0 http://tools.ietf.org/html/draft-peterson-secure-= origin-ps-00
>
> =A0 Authenticated Identity Management in the Session Initiation
> =A0 Protocol (SIP)
> =A0 http://tools.ietf.org/html/draft-jennings-disp= atch-rfc4474bis-00
>
> A likely approach for SIP-based authorization validation is to include= a
> new capability for Identity assertions to cover telephone numbers,
> rather than domain names. To conform with realistic deployments.
>
> The working group will coordinate with the security area, for any
> proposal details that utilize classic security mechanisms, such as
> cryptography and certificate credentials.
>
> The working group will coordinate with RAI area groups studying the > problem of signaling through existing deployments, including activitie= s
> in the INSIPID and STRAW working groups.
>
> Identity is closely linked to privacy, and frequently one comes at the=
> cost of the other. To the extent feasible the working group will favor=
> privacy-friendly choices that minimize call information leakage to thi= rd
> parties.
>
> The working group will deliver the following:
>
> - Problem statement detailing the deployment environment and
> =A0difficulties motivating work on secure origins
>
> - Specification of an authorization validation method for the source > =A0telephone number identity of a SIP request (in the From
> =A0field)
>
> - Specification of the means for obtaining security-related parametric=
> =A0information, used to perform source telephone number identity
> =A0authorization validation.
>
>
> Milestones
>
> Sep 2013 =A0 Submit problem statement for Info
> Dec 2013 =A0 Submit STIR authorization validation method for PS
> Mar 2013 =A0 Submit STIR parametric information draft for PS
>
>
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> --
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

--047d7bf0e0525e3d6d04e0265e2f-- From jon.peterson@neustar.biz Thu Jun 27 10:48: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 2389721F9E82 for ; Thu, 27 Jun 2013 10:48: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 yErUKLJ9ZjAr for ; Thu, 27 Jun 2013 10:48:55 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 14B7621F9E47 for ; Thu, 27 Jun 2013 10:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372355284; x=1687711990; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=SaCEoSv1cI LY0ibfLpAslM6w6uHZf0oFuYwTPEnfZH8=; b=Nq/BUH0K+PBcK21UBlmR6MIhXI SVV7g2aVy2no5WkeRK6o5w7RNsA+6Yq/A9RL0s5T9xDPumZgip2JtFSGJ1RA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21514200; Thu, 27 Jun 2013 13:48:03 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 13:48:45 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , "dcrocker@bbiw.net" Thread-Topic: [stir] Revised charter text for STIR Thread-Index: AQHOc0RP7qgb0/rNTkuQHAXjKZBP65lKCYKA//+ayYA= Date: Thu, 27 Jun 2013 17:48:44 +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.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ac5B/vdaQmMkX/3GhZUq8Q== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 17:48:59 -0000 The "input" drafts wouldn't be listed in a charter I don't think, but for a BoF it is common to include them in the announcement. Some of them will probably be iterated before I-D cut-off, so I might refer to their tracker page rather than the -00s directly. I think this version of the charter generally is a crisp and appropriately narrow description of the in-band problem. Setting aside the question of whether that is the best scope to choose, a few places off the bat I'd have concerns: - The potential interpretation of "the entity formally assigned use of that number." That can be read in a number of ways, some of which will close doors that need to remain open, I think. There are multiple assignments that take place, from the ITU-T down to national regulators, from regulators to carriers, from carriers to end users, with various resellers and enterprises stuck in the middle. Is one of these assignments formal and the others not, or are all of them potentially in play? To leave open possibilities, I might gloss over this with "an entity assigned use of the number." - The deliverable for "the means of obtaining security-related parametric information." The literal means of obtaining keys/credentials, I think, are in the scope of the authorization validation method deliverable - for RFC4474, for example, this was the Identity-Info header and the URI schemes it described. You certainly can't do authorization validation without that means. I could read this deliverable as if it's suggesting that header or mechanism should be in a separate document. The original charter had "key management" as a separate deliverable, which is a slightly different scope. - The charter should be clear that we intend to obsolete RFC4474 and replace it with something, regardless of whether or not that happens to be one of our current input drafts. Jon Peterson Neustar, Inc. On 6/27/13 9:50 AM, "Hadriel Kaplan" wrote: > >I like this charter much more - I think it avoids the contentious aspects >that could drag down the BOF, while at the same time narrows the scope of >initial work to do. > >I have one nit-pick though: I don't think it should list/mention the >individual drafts as "input" to the WG. Listing the RFCs makes sense, >but the individual drafts are just individual drafts, and there are a lot >more that have been submitted over the years that we could dredge up as >input. Is it meant as just a reading list type thing for background? Do >we put that in charters typically? > >-hadriel > > >On Jun 27, 2013, at 10:40 AM, Dave Crocker wrote: > >> Folks, >>=20 >> Based on the apparent trend on the list to favor a narrower working >>group charter, as well as the rest of what has been discussed on the >>list, here is revised draft charter text to consider. >>=20 >> It focuses on specification of an authorization validation method and a >>method for getting the information needed to perform validation. The >>example of the first is signature in an identity field. The example of >>the latter is a query to an external database, to get keys, credentials >>or the like. But the language is intentionally non-technical, in order >>to leave the technical choices to the working group. Hence, for >>example, it does not attempt to resolve the choice between "credential" >>or "public key", nor HTTP vs. DNS. >>=20 >> It removes details that are not essential to the work and that might >>invite irrelevant debate. >>=20 >> The first paragraph is designed to stand alone as a summary abstract; >>this is actually a formal requirement for charter text, since the first >>paragraph is what's circulated in announcements. >>=20 >>=20 >> d/ >>=20 >>=20 >>=20 >>=20 >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >>=20 >> Chairs: TBD >> Area Advisor: TBD (Barnes) >>=20 >> Mailing list: https://www.ietf.org/mailman/listinfo/stir >> To Subscribe: -- >>=20 >>=20 >> As with email, the claimed source identity of a SIP request (in the From >> field) is not verified. As with email, this permits and produces >> unauthorized use of source identities as part of deceptive and coercive >> activities, such as bulk unsolicited commercial communications, >> voicemail hacking, and impersonating banks. The current effort will >> specify a mechanism to support validation that a telephone number's >> presence in the SIP From field is authorized by the entity formally >> assigned use of that number, or by their delegate. The mechanism will >> support end-to-end SIP interactions. Initial specification will be in >> terms of a pure-SIP exchange, which will serve as the operational base. >> Additional mechanisms might later be developed to support more >> complicated mediation scenarios. >>=20 >> The working group will consider choices for the method of specifying >> authorization information and the means of obtaining the parametric >> information needed to perform that authorization check. An example of >> the first could be use of a cryptographically-protected field carried by >> SIP and containing identity and authentication information. An example >> of the second could be a mechanism for querying an external database, to >> obtain the key-signing parameters for the authentication cryptography. >>=20 >> A number of previous efforts have attacked the problem of securing the >> origins of SIP communications, including RFC3325, RFC4474 and the VIPR >> working group. To date, however, true validation of the source of SIP >> calls has not seen any appreciable deployment. While several factors >> contributed to this lack of success, culprits included: failure of the >> problem to be seen as critical at the time; lack of any real means of >> asserting authority over telephone numbers on the Internet; misalignment >> of the mechanisms proposed by RFC4474 with the complex deployment >> environment that has emerged for SIP; and inherent operational problems >> with a transitive trust model. >>=20 >>=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 >> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >>=20 >> Secure Origin Identification: Problem Statement, Requirements, >> and Roadmap >> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >>=20 >> Authenticated Identity Management in the Session Initiation >> Protocol (SIP) >> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 >>=20 >> A likely approach for SIP-based authorization validation is to include a >> new capability for Identity assertions to cover telephone numbers, >> rather than domain names. To conform with realistic deployments. >>=20 >> The working group will coordinate with the security area, for any >> proposal details that utilize classic security mechanisms, such as >> cryptography and certificate credentials. >>=20 >> The working group will coordinate with RAI area groups studying the >> problem of signaling through existing deployments, including activities >> in the INSIPID and STRAW working groups. >>=20 >> Identity is closely linked to privacy, and frequently one comes at the >> cost of the other. To the extent feasible the working group will favor >> privacy-friendly choices that minimize call information leakage to third >> parties. >>=20 >> The working group will deliver the following: >>=20 >> - Problem statement detailing the deployment environment and >> difficulties motivating work on secure origins >>=20 >> - Specification of an authorization validation method for the source >> telephone number identity of a SIP request (in the From >> field) >>=20 >> - Specification of the means for obtaining security-related parametric >> information, used to perform source telephone number identity >> authorization validation. >>=20 >>=20 >> Milestones >>=20 >> Sep 2013 Submit problem statement for Info >> Dec 2013 Submit STIR authorization validation method for PS >> Mar 2013 Submit STIR parametric information draft for PS >>=20 >>=20 >>=20 >>=20 >> --=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >>=20 >> --=20 >> 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 richard@shockey.us Thu Jun 27 11:06: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 0A78221F9E8A for ; Thu, 27 Jun 2013 11:06:20 -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 yp6HQak0K-3A for ; Thu, 27 Jun 2013 11:06: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 520A021F9E87 for ; Thu, 27 Jun 2013 11:06:15 -0700 (PDT) Received: (qmail 2450 invoked by uid 0); 27 Jun 2013 18:05:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 27 Jun 2013 18:05:43 -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=Xy1msJoSAnEmGRLCAZUF7wxaAJ+/v1nAhls2TlqPTLk=; b=IZRsp7MYP78ThILH6Oucz34Uyv6KtiG3PYKPa0Z+KOzxgyleEJPoi9VLZ2VQVM+hrjx4EzjRF0AEZH62aVE45oecqjyFciA4n2TWMz3uDpMPBQga+12VOQMi0XW2UdbI; Received: from [72.66.111.124] (port=50075 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UsGZi-0005gh-9d; Thu, 27 Jun 2013 12:05:42 -0600 From: "Richard Shockey" To: "'Peterson, Jon'" , "'Hadriel Kaplan'" , References: In-Reply-To: Date: Thu, 27 Jun 2013 14:05:39 -0400 Message-ID: <002d01ce7360$efeec3a0$cfcc4ae0$@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: AQHRUkg+NyZplJThm8doo7YvYaatzplEHOaQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 18:06:20 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Thursday, June 27, 2013 1:49 PM To: Hadriel Kaplan; dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] Revised charter text for STIR The "input" drafts wouldn't be listed in a charter I don't think, but for a BoF it is common to include them in the announcement. Some of them will probably be iterated before I-D cut-off, so I might refer to their tracker page rather than the -00s directly. I think this version of the charter generally is a crisp and appropriately narrow description of the in-band problem. Setting aside the question of whether that is the best scope to choose, a few places off the bat I'd have concerns: - The potential interpretation of "the entity formally assigned use of that number." That can be read in a number of ways, some of which will close doors that need to remain open, I think. There are multiple assignments that take place, from the ITU-T down to national regulators, from regulators to carriers, from carriers to end users, with various resellers and enterprises stuck in the middle. Is one of these assignments formal and the others not, or are all of them potentially in play? To leave open possibilities, I might gloss over this with "an entity assigned use of the number." [RS> ] [RS> ] Speaking of ITU ..did you all see this ..note internally the reference to phone numbers etc. Richard Hill was the Counselor to ITU-T Title : "Non Accession to the ITRs Considered Harmful" Author(s) : Richard Hill Filename : draft-hill-itr-non-accession-harmful-00.txt Pages : 10 Date : 2013-06-25 Abstract: One of the treaties administered by the International Telecommunications Union is the International Telecommunications Regulations (ITRs), whose purpose is to promote the development of telecommunication services. The 1988 version of the ITRs opened the way for privatisation, liberalization, and the growth of the Internet and mobile networks. Given the subsequent significant structure and technological changes, the ITU membership agreed to meet in 2012 to revise the ITRs. While consensus was found on an overwhelming majority of the treaty text, some provisions proved to be controversial, leading to a split in the membership and sharp criticism of selected provisions. As a result, some ITU Member States did not sign the treaty. This document analyses that criticism and attempts to place it in context; it identifies problems that may arise if states to not accede to the treaty, and suggests a way forward, concluding that not acceding may have undesirable results for the citizens of non-signatory countries and for interoperability in general. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hill-itr-non-accession-harmful - The deliverable for "the means of obtaining security-related parametric information." The literal means of obtaining keys/credentials, I think, are in the scope of the authorization validation method deliverable - for RFC4474, for example, this was the Identity-Info header and the URI schemes it described. You certainly can't do authorization validation without that means. I could read this deliverable as if it's suggesting that header or mechanism should be in a separate document. The original charter had "key management" as a separate deliverable, which is a slightly different scope. - The charter should be clear that we intend to obsolete RFC4474 and replace it with something, regardless of whether or not that happens to be one of our current input drafts. Jon Peterson Neustar, Inc. On 6/27/13 9:50 AM, "Hadriel Kaplan" wrote: > >I like this charter much more - I think it avoids the contentious >aspects that could drag down the BOF, while at the same time narrows >the scope of initial work to do. > >I have one nit-pick though: I don't think it should list/mention the >individual drafts as "input" to the WG. Listing the RFCs makes sense, >but the individual drafts are just individual drafts, and there are a >lot more that have been submitted over the years that we could dredge >up as input. Is it meant as just a reading list type thing for >background? Do we put that in charters typically? > >-hadriel > > >On Jun 27, 2013, at 10:40 AM, Dave Crocker wrote: > >> Folks, >> >> Based on the apparent trend on the list to favor a narrower working >>group charter, as well as the rest of what has been discussed on the >>list, here is revised draft charter text to consider. >> >> It focuses on specification of an authorization validation method and >>a method for getting the information needed to perform validation. >>The example of the first is signature in an identity field. The >>example of the latter is a query to an external database, to get keys, >>credentials or the like. But the language is intentionally >>non-technical, in order to leave the technical choices to the working >>group. Hence, for example, it does not attempt to resolve the choice between "credential" >>or "public key", nor HTTP vs. DNS. >> >> It removes details that are not essential to the work and that might >>invite irrelevant debate. >> >> The first paragraph is designed to stand alone as a summary abstract; >>this is actually a formal requirement for charter text, since the >>first paragraph is what's circulated in announcements. >> >> >> d/ >> >> >> >> >> Name: Secure Telephone Identity Revisited (stir) >> Area: RAI >> >> Chairs: TBD >> Area Advisor: TBD (Barnes) >> >> Mailing list: https://www.ietf.org/mailman/listinfo/stir >> To Subscribe: -- >> >> >> As with email, the claimed source identity of a SIP request (in the >> From >> field) is not verified. As with email, this permits and produces >> unauthorized use of source identities as part of deceptive and >> coercive activities, such as bulk unsolicited commercial >> communications, voicemail hacking, and impersonating banks. The >> current effort will specify a mechanism to support validation that a >> telephone number's presence in the SIP From field is authorized by >> the entity formally assigned use of that number, or by their >> delegate. The mechanism will support end-to-end SIP interactions. >> Initial specification will be in terms of a pure-SIP exchange, which will serve as the operational base. >> Additional mechanisms might later be developed to support more >> complicated mediation scenarios. >> >> The working group will consider choices for the method of specifying >> authorization information and the means of obtaining the parametric >> information needed to perform that authorization check. An example of >> the first could be use of a cryptographically-protected field carried >> by SIP and containing identity and authentication information. An >> example of the second could be a mechanism for querying an external >> database, to obtain the key-signing parameters for the authentication cryptography. >> >> A number of previous efforts have attacked the problem of securing >> the origins of SIP communications, including RFC3325, RFC4474 and the >> VIPR working group. To date, however, true validation of the source >> of SIP calls has not seen any appreciable deployment. While several >> factors contributed to this lack of success, culprits included: >> failure of the problem to be seen as critical at the time; lack of >> any real means of asserting authority over telephone numbers on the >> Internet; misalignment of the mechanisms proposed by RFC4474 with the >> complex deployment environment that has emerged for SIP; and inherent >> operational problems with a transitive trust model. >> >> >> 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 >> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >> >> Secure Origin Identification: Problem Statement, Requirements, >> and Roadmap >> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >> >> Authenticated Identity Management in the Session Initiation >> Protocol (SIP) >> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 >> >> A likely approach for SIP-based authorization validation is to >> include a new capability for Identity assertions to cover telephone >> numbers, rather than domain names. To conform with realistic deployments. >> >> The working group will coordinate with the security area, for any >> proposal details that utilize classic security mechanisms, such as >> cryptography and certificate credentials. >> >> The working group will coordinate with RAI area groups studying the >> problem of signaling through existing deployments, including >> activities in the INSIPID and STRAW working groups. >> >> Identity is closely linked to privacy, and frequently one comes at >> the cost of the other. To the extent feasible the working group will >> favor privacy-friendly choices that minimize call information leakage >> to third parties. >> >> The working group will deliver the following: >> >> - Problem statement detailing the deployment environment and >> difficulties motivating work on secure origins >> >> - Specification of an authorization validation method for the source >> telephone number identity of a SIP request (in the From >> field) >> >> - Specification of the means for obtaining security-related >> parametric information, used to perform source telephone number >> identity authorization validation. >> >> >> Milestones >> >> Sep 2013 Submit problem statement for Info >> Dec 2013 Submit STIR authorization validation method for PS >> Mar 2013 Submit STIR parametric information draft for PS >> >> >> >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> -- >> 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From jon.peterson@neustar.biz Thu Jun 27 11:16: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 C19D721F9E7E for ; Thu, 27 Jun 2013 11:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.323 X-Spam-Level: X-Spam-Status: No, score=-106.323 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 pI4f2buJlWmN for ; Thu, 27 Jun 2013 11:16:54 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B42DB21F9E7B for ; Thu, 27 Jun 2013 11:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372357188; x=1687715830; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=JDA36Rj5BV iGfV2wjwzMrODT8Is5hcSIGN5n0pzpbMA=; b=IgyYBZeg28TMya7Em2PhccglPY Vz8rGFKVD3tROLibzLR/MdTfqk1+nLA3j/6Rk0Lz+Zn4VcHfazLmBiDvclYA== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25789539; Thu, 27 Jun 2013 14:19:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 14:16:45 -0400 From: "Peterson, Jon" To: Hadriel Kaplan , Michael Hammer Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnbsMmZQTrk9EapAINY/F31vZk+4muAgAAHWYCAACgJgIABI2sAgACC9gCABJqygIAA53gAgABygoCAACfSAIAACiiAgAAVTgCAAAL9AIAAIBoAgADZkICAAF9KAIAAA26AgACLhoCAAAMNAIAACYQAgAAqmgCAAC/OAIAAvjyAgAAOJwD//6URAA== Date: Thu, 27 Jun 2013 18:16:44 +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.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uGZ4acfjyz5L8iiJewBEMQ== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 18:16:58 -0000 >It does not matter if it started as 'sip:5551212@aaa.com;user=3Dphone' and >got received as 'sip:+1-212-555-1212@bbb.com'; because if the terminator >uses it as the E.164 phone number '12125551212' in his systems and >caller-id displays, then what he really needs to know is that this call >request came from someone with the authority to claim '12125551212' - he >does *not* need to know it really came from 'bbb.com', nor that it came >from user '+1-212-555-1212', nor even that it came from SIP. Perhaps what some folks are missing here is the clear statement that both the auth service and the verification service need to canonicalize the >From number to E.164 (actually a bit of a variant, but glossing over for now) as a part of the signature generation/verification process. The idea is basically this: when the auth signature is placed over sip:5551212@aaa.com, the auth service canonicalizes 5551212 to "12125551212", and that is what is signed over in the digest-strig of the Identity header. In RFC4474 terms, this canonicalized string would take the place of the addr-spec of the AoR in Section 9. When the verification service receives +1-212-555-1212@bbb.com, it too canonicalizes that to 12125551212 for the purposes of regenerating the digest-string. Thus it doesn't matter how From is munged. Nor do you need to store a copy of the number anywhere in the message, which for the various reasons previously discussed won't work. The requirement here that both the auth service and verification service canonicalize numbers in the same fashion is absolute, and perhaps non-trivial, but it's certainly way better than hop-by-hop protection. Jon Peterson Neustar, Inc. From hadriel.kaplan@oracle.com Thu Jun 27 12: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 656D321F9F12 for ; Thu, 27 Jun 2013 12:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 H6hjM9DRXczx for ; Thu, 27 Jun 2013 12:14:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C9EED21F9F0F for ; Thu, 27 Jun 2013 12:14: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 r5RJ8D35029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 19:08:14 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 r5RJEVXM003851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 19:14:32 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5RJEV9p003846; Thu, 27 Jun 2013 19:14:31 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 12:14:31 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 27 Jun 2013 15:14:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: [stir] Replacing rfc4474 (was: Revised charter text for 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, 27 Jun 2013 19:14:44 -0000 On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" = wrote: > - The charter should be clear that we intend to obsolete RFC4474 and > replace it with something, regardless of whether or not that happens = to be > one of our current input drafts. It's likely that the resulting outcome of this WG ends up being a much = narrower assertion of stuff being protected/authenticated - in = particular, it might only end up protecting the caller-id for a given = request, and nothing more. ISTM that rfc4474 tried to 'protect' things = that went beyond simply the caller-id of a request. So if we *only* = protect the caller-id, will you be comfortable with replacing RFC4474? -hadriel From pkyzivat@alum.mit.edu Thu Jun 27 12:59: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 6FC4121F9A0C for ; Thu, 27 Jun 2013 12:59:05 -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 F5oF2zh3el6P for ; Thu, 27 Jun 2013 12:58:59 -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 7969121F9A00 for ; Thu, 27 Jun 2013 12:58:59 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id tS2t1l0081ZXKqc56XyyNH; Thu, 27 Jun 2013 19:58:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id tXyy1l0123ZTu2S3hXyyZq; Thu, 27 Jun 2013 19:58:58 +0000 Message-ID: <51CC9982.4060502@alum.mit.edu> Date: Thu, 27 Jun 2013 15:58:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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=1372363138; bh=HfRFf5o2xzm186EAbppVWU69E+v9ZKk2gu9KvlhNb1A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qmNr2p7I51IoH6TEFkBfdiae8Fen3I8MOoY/WTk4C53BJoCCDQQVJsZO661FO/TSV FLjkTZyEGEmfi1T4/9oog4pDyrjH/5QOVA5P/SZY3Esd3nYZgpEr38pWH6DjLfPxrF ZDsael7luboZDuKT3Sq7E2DU17nvXe24R2LEueUnqJgPJBN+mm9f6C2SPZYTW3w4QA DIsWQsE3tWNO8gRM37Jx91wx7yvFPyDtYJ/Kyhr8O8OxyedAmdggHvKS8HfM6f/n0O jZX7dOq4aMFFNXUSkn5aDsWLHTMY3xaJiRzatyQCbS62/NzV/9WkQ8Q1VGh68Sc5ua J8HH25Rx+fg3w== Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 19:59:05 -0000 On 6/27/13 1:48 PM, Peterson, Jon wrote: > - The charter should be clear that we intend to obsolete RFC4474 and > replace it with something, regardless of whether or not that happens to be > one of our current input drafts. You mean replace it for non-number URIs too? While there may be good reason to do that, it seems like the issues are different, and trying to do both together might be distracting. Thanks, Paul From jon.peterson@neustar.biz Thu Jun 27 13:06: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 5BFBF11E80F9 for ; Thu, 27 Jun 2013 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 4iAEuIkAZY0y for ; Thu, 27 Jun 2013 13:06:14 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69111E80F2 for ; Thu, 27 Jun 2013 13:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372363469; x=1687721114; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=7By9nwmHj9 K2zbKgnQBGLzHVeFtj9HxQC1em+yc+yqo=; b=GhcITPVIlTumBp1QsUGbkLbsvT sAbv5op+3n68FR7+q1od9xTCR5p0OMU/ZiitgFToh0c4A4HH7FtUsyJkSYKg== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20080149; Thu, 27 Jun 2013 16:04:27 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 16:06:03 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlJylwA Date: Thu, 27 Jun 2013 20:06:02 +0000 Message-ID: In-Reply-To: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pvjKC61w21vuFyxlIv2zcw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 27 Jun 2013 20:06:18 -0000 There are some areas of ambiguity here, definitely, about the scope of RFC4474 against the current work. A lot of this comes down to questions we've discussed before: dealing with non-INVITE requests and defining the threat of impersonation properly. If, extending the analogy to email, you could secure the From header but not the body of the message, would it be "impersonation" when someone changed the message body so that it appeared you were saying something different than you intended? We agreed coming in to this to scope the threat model such that a man-in-the-middle modifying SDP, for example, changing m=3D or c=3D lines, would not break the signature protecting caller ID. Personally, I think there is value for impersonation protection in some environments and scenarios in detecting change in message bodies - for non-INVITE requests (MESSAGE, say), protecting security parameters in SDP which support SRTP, etc. I think there are ways to design the overall mechanism that can reconcile those two requirements. Some kind of separate signature over the body, where the body signature would be optionally added by the authentication service, is something we've discussed before. Maybe there should be a special case for parameters relevant to SRTP. I don't think we need a fully-baked solution at this point, but yes, I'd want that to be part of the discussion of where we go with any identity mechanism for SIP. Moreover, loosening the threat model when it comes to men-in-the-middle doesn't mean we should ignore replay attacks. When you say "caller-id for a given request, and nothing more," taken literally that would probably fall short of the bar of protecting against cut-and-paste attacks. So no, I don't think it's reasonable to say the scope of this is protecting only the calling party number. Jon Peterson Neustar, Inc. On 6/27/13 12:14 PM, "Hadriel Kaplan" wrote: > >On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" >wrote: > >> - The charter should be clear that we intend to obsolete RFC4474 and >> replace it with something, regardless of whether or not that happens to >>be >> one of our current input drafts. > >It's likely that the resulting outcome of this WG ends up being a much >narrower assertion of stuff being protected/authenticated - in >particular, it might only end up protecting the caller-id for a given >request, and nothing more. ISTM that rfc4474 tried to 'protect' things >that went beyond simply the caller-id of a request. So if we *only* >protect the caller-id, will you be comfortable with replacing RFC4474? > >-hadriel > From housley@vigilsec.com Thu Jun 27 14:20: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 7F29621F9D59 for ; Thu, 27 Jun 2013 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 qBlvirJ+0lkA for ; Thu, 27 Jun 2013 14:20:42 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D7EB121F9D52 for ; Thu, 27 Jun 2013 14:20:41 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8F78DF2407E; Thu, 27 Jun 2013 17:20:45 -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 KBLCy2sUNS1h; Thu, 27 Jun 2013 17:20:39 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8B562F24078; Thu, 27 Jun 2013 17:20:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51CC4ED6.30408@dcrocker.net> Date: Thu, 27 Jun 2013 17:20:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51CC4ED6.30408@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1085) Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 21:20:47 -0000 Dave: Thanks for proposing text. There are places where there is obvious = improvement, but there are other places that raise concern for me. = Comments below. Russ > Name: Secure Telephone Identity Revisited (stir) > Area: RAI >=20 > Chairs: TBD > Area Advisor: TBD (Barnes) >=20 > Mailing list: https://www.ietf.org/mailman/listinfo/stir > To Subscribe: -- >=20 >=20 > As with email, the claimed source identity of a SIP request (in the = From > field) is not verified. As with email, this permits and produces > unauthorized use of source identities as part of deceptive and = coercive > activities, such as bulk unsolicited commercial communications, > voicemail hacking, and impersonating banks. The current effort will > specify a mechanism to support validation that a telephone number's > presence in the SIP =46rom field is authorized by the entity formally > assigned use of that number, or by their delegate. The mechanism will > support end-to-end SIP interactions. Initial specification will be in > terms of a pure-SIP exchange, which will serve as the operational = base. > Additional mechanisms might later be developed to support more > complicated mediation scenarios. I do not think "As with email" helps in the first two sentences. SIP is = a fairly well understood protocol in the IETF, so we can just talk about = it. The last sentence is confusing to me. The previous sentences say that = the WG will develop a mechanism, and then the last sentence calls for = additional ones in "complicated mediation scenarios". Since mediation = has not come up in this text before, I am not sure what it means here. > The working group will consider choices for the method of specifying > authorization information and the means of obtaining the parametric > information needed to perform that authorization check. An example of > the first could be use of a cryptographically-protected field carried = by > SIP and containing identity and authentication information. An example > of the second could be a mechanism for querying an external database, = to > obtain the key-signing parameters for the authentication cryptography. I suggest this should be higher level description. I suggest: The working group will consider choices for the method of specifying authorization information and the means of authenticating and validating this information. For example, a cryptographically-protected field = carried by SIP could contain identity and authentication information, and then a database could be queried to obtain the keying material to perform the authentication checking. > A number of previous efforts have attacked the problem of securing the > origins of SIP communications, including RFC3325, RFC4474 and the VIPR > working group. To date, however, true validation of the source of SIP > calls has not seen any appreciable deployment. While several factors > contributed to this lack of success, culprits included: failure of the > problem to be seen as critical at the time; lack of any real means of > asserting authority over telephone numbers on the Internet; = misalignment > of the mechanisms proposed by RFC4474 with the complex deployment > environment that has emerged for SIP; and inherent operational = problems > with a transitive trust model. All good. Perhaps a sentence about why we think the time is better now = would complete this thought. > 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 > http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >=20 > Secure Origin Identification: Problem Statement, Requirements, > and Roadmap > http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >=20 > Authenticated Identity Management in the Session Initiation > Protocol (SIP) > http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 Others has suggested that this is important for these to be available to = BOF participants, but several people have suggested removing it from the = charter. I think that the problem statement could remain, but if other object, I = an not hard over on it. > A likely approach for SIP-based authorization validation is to include = a > new capability for Identity assertions to cover telephone numbers, > rather than domain names. To conform with realistic deployments. I'd like to see the same rigor that you used earlier applied to this = paragraph. I think the mechanism and validation are not clearly = separated in this description. > The working group will coordinate with the security area, for any > proposal details that utilize classic security mechanisms, such as > cryptography and certificate credentials. >=20 > The working group will coordinate with RAI area groups studying the > problem of signaling through existing deployments, including = activities > in the INSIPID and STRAW working groups. >=20 > Identity is closely linked to privacy, and frequently one comes at the > cost of the other. To the extent feasible the working group will favor > privacy-friendly choices that minimize call information leakage to = third > parties. >=20 > The working group will deliver the following: >=20 > - Problem statement detailing the deployment environment and > difficulties motivating work on secure origins Maybe the starting point of draft-cooper-iab-secure-origin-00 goes here. > - Specification of an authorization validation method for the source > telephone number identity of a SIP request (in the From > field) >=20 > - Specification of the means for obtaining security-related parametric > information, used to perform source telephone number identity > authorization validation. I think that the last deliverable should focus on the validation of the = authorization information. Yes, we will have to specify all the steps, = but the description should not already assume that not inserted by the = caller. Russ From Henning.Schulzrinne@fcc.gov Thu Jun 27 14:28: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 4C36E21F9926 for ; Thu, 27 Jun 2013 14:28:05 -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 3d8s4jY0HZqY for ; Thu, 27 Jun 2013 14:28:00 -0700 (PDT) Received: from GB-IP-2.fcc.gov (mail4.fcc.gov [208.31.254.167]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9B11E80F2 for ; Thu, 27 Jun 2013 14:27:57 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan , "Peterson, Jon" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lKEhkH Date: Thu, 27 Jun 2013 21:27:55 +0000 References: , <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> In-Reply-To: <42E86894-05FF-4D3B-B430-8E5660C44132@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" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 27 Jun 2013 21:28:05 -0000 Several outcomes are possible, and it seems unnecessary to pick one at this= time:=0A= =0A= - Leave 4474 alone and create something suited to STIR E.164 needs that can= co-exist with 4474, but is otherwise independent (new header field, new lo= gic, etc.).=0A= =0A= - Update 4474 for the number case (and more limited signing).=0A= =0A= - Replace 4474, and thus address both E.164 (tel/SIP) and non-E.164 SIP URL= s.=0A= =0A= This will partially depend on the "how to look up certs/public keys" debate= outcome, so I see little advantage in picking one of the options now. Whil= e I don't think we'd intentionally break 4474 implementations, should they = exist, without good cause, backward compatibility isn't the primary concern= here, unlike in other "bis" efforts where everybody wants to be assured th= at the new effort at least won't break old boxes.=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hadriel Ka= plan [hadriel.kaplan@oracle.com]=0A= Sent: Thursday, June 27, 2013 3:14 PM=0A= To: Peterson, Jon=0A= Cc: stir@ietf.org; dcrocker@bbiw.net=0A= Subject: [stir] Replacing rfc4474 (was: Revised charter text for STIR)=0A= =0A= On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" wro= te:=0A= =0A= > - The charter should be clear that we intend to obsolete RFC4474 and=0A= > replace it with something, regardless of whether or not that happens to b= e=0A= > one of our current input drafts.=0A= =0A= It's likely that the resulting outcome of this WG ends up being a much narr= ower assertion of stuff being protected/authenticated - in particular, it m= ight only end up protecting the caller-id for a given request, and nothing = more. ISTM that rfc4474 tried to 'protect' things that went beyond simply = the caller-id of a request. So if we *only* protect the caller-id, will yo= u be comfortable with replacing RFC4474?=0A= =0A= -hadriel=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From michael.hammer@yaanatech.com Thu Jun 27 14:53: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 CCF5B21F9A7D for ; Thu, 27 Jun 2013 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 McwP4IAellRt for ; Thu, 27 Jun 2013 14:53: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 2490721F9B81 for ; Thu, 27 Jun 2013 14:53:14 -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, 27 Jun 2013 14:53:10 -0700 From: Michael Hammer To: "jon.peterson@neustar.biz" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlg Date: Thu, 27 Jun 2013 21:53:09 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0098_01CE7346.0A29CE60" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 27 Jun 2013 21:53:22 -0000 ------=_NextPart_000_0098_01CE7346.0A29CE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree. But, I may be looking for something a little more stringent. First, you have to have a string that has a canonical form. If it is not, then the string is likely something out of scope. Second, you have to have a place in a header that you can be guaranteed to find that canonical form. We seem to be very squishy about that. I don't want to have to know the secret hand-shake to understand that. (Standard versus clubs) A recipient should not have to have a different flavor or handling for aaa.com or bbb.com, or ... Note, what someone does intra-domain may not matter. At least at the inter-domain boundary, be standard. Third, if the normal rules state that the context of a string is defined by a domain and not by the standard, and, since you have previously stated (I think) that the domain can do whatever it wants with the user part, then I really can't know that any user part string is an E.164 or something else. So, if it is within the scope of a domain, all bets are off. The degree of flexibility you want to preserve is probably directly proportional to the degree of non-interoperability you will get. Mike -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Thursday, June 27, 2013 11:17 AM To: Hadriel Kaplan; Michael Hammer Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >It does not matter if it started as 'sip:5551212@aaa.com;user=phone' >and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >terminator uses it as the E.164 phone number '12125551212' in his >systems and caller-id displays, then what he really needs to know is >that this call request came from someone with the authority to claim >'12125551212' - he does *not* need to know it really came from >'bbb.com', nor that it came from user '+1-212-555-1212', nor even that it came from SIP. Perhaps what some folks are missing here is the clear statement that both the auth service and the verification service need to canonicalize the From number to E.164 (actually a bit of a variant, but glossing over for now) as a part of the signature generation/verification process. The idea is basically this: when the auth signature is placed over sip:5551212@aaa.com, the auth service canonicalizes 5551212 to "12125551212", and that is what is signed over in the digest-strig of the Identity header. In RFC4474 terms, this canonicalized string would take the place of the addr-spec of the AoR in Section 9. When the verification service receives +1-212-555-1212@bbb.com, it too canonicalizes that to 12125551212 for the purposes of regenerating the digest-string. Thus it doesn't matter how From is munged. Nor do you need to store a copy of the number anywhere in the message, which for the various reasons previously discussed won't work. The requirement here that both the auth service and verification service canonicalize numbers in the same fashion is absolute, and perhaps non-trivial, but it's certainly way better than hop-by-hop protection. Jon Peterson Neustar, Inc. ------=_NextPart_000_0098_01CE7346.0A29CE60 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NzIxNTMwOVowIwYJKoZIhvcNAQkEMRYEFNhH1bApOTqCXvputj358+h7RglrMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAP63zjPO5hiROay6qCdjxXThPpkh+rO0MyHqVqWUz PyVMRY70zBguiph9aDaiYNXdwB+e4bHS/m55BflmG6zfhEHPecjY93Dhl0LtnNJzf4d9KnlrU4Xm lNlcXL2TOi1S9+uIYcyDHJAh60ZfaAnhaHiotxd/6zllJnCETtDtdCo6yOCW/d4hChNKMigoX8LS 3QPD03zLyAWLrGcW8AnxDcpHVoS2mY5S1WzbuYZql0NUYfZjpr5wwhIOgxcZHFBUaSXjkI52yZM9 J2JnIgcBraAwgeIbdwyE+GRtzej04cMWATZU5QYRLK9H6URch1VH9Jk/UFGYb2xw7hjarnVfhQAA AAAAAA== ------=_NextPart_000_0098_01CE7346.0A29CE60-- From hadriel.kaplan@oracle.com Thu Jun 27 15:06: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 D59CD21F9B6A for ; Thu, 27 Jun 2013 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 zFYfh6lQq71h for ; Thu, 27 Jun 2013 15:06:06 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 531E721F9B66 for ; Thu, 27 Jun 2013 15:06:06 -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 r5RLxfDj011447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 21:59:42 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 r5RM60kP014602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 22:06:00 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 r5RM5xO9002766; Thu, 27 Jun 2013 22:05:59 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 15:05:59 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 27 Jun 2013 18:06:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1F10D3A5-D2C8-4088-A80E-4683822C5B1E@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 27 Jun 2013 22:06:12 -0000 Up front I should be clear about one thing: I thought we had been told = that the real-world problem we need to solve and focus on and quickly = fix is bogus/spoofed caller-id. I'm not saying we might not also end up = solving other things simultaneously with the same mechanism, enough so = that we can really replace RFC4474 - I'm just saying we shouldn't be = constrained to having to do so by putting it in the charter right now. = It might turn out we can replace 4474, but we don't know that yet. I agree that we could come up with some way to provide optional = protection for the SDP or parts thereof, even with the ability to verify = the caller-id while failing to verify the SDP all with one signature. = The problem is it wouldn't be of any use. It gets back to the notion of = there being different levels of security - shades of gray - that somehow = users could distinguish between somewhat-secure and somewhat-more-secure = calls. And the truth is it would only be "somewhat-more-secure", not actually = "secure", for the same reasons that using DTLS-SRTP doesn't truly = provide "secure" end-to-end media even in WebRTC. You'd need an = out-of-band, real endpoint-to-endpoint, trusted-third-party assurance = model for that; something like EKR's IdP proposal for WebRTC might get = close, for example. But if you have some out-of-band mechanism, then = you don't need a STIR in-band mechanism to protect the SDP at all - it's = superfluous. Furthermore, I think most people here agree that the SDP-portion would = change virtually all the time today, which means that that part of the = assertion will fail all the time today. So adding that portion is = useless today, if not outright counter-productive to getting STIR = adopted. So skip forward to the future, at some point the extra = assertion might start succeeding on a few calls somewhere. Then what? = Do you start rejecting calls that don't succeed at it? Even if most = calls succeed with it, do you reject the rest? What is this = distinguishing security assertion useful for, to either machines or = humans? So let's talk about the replay and cut-and-paste attack scenarios. = Let's assume we all agreed we need to prevent them - since we know the = SDP portion of the assertion will fail most of the time today, shouldn't = we be trying to prevent them regardless of the SDP being changed or not = by transit domains, so that we can protect the caller-id from such an = attack today? There is a very popular Enterprise PBX vendor that = by-default sends INVITEs without SDP - are we saying calls from those = PBXs can't have their caller-id's protected as strongly as from other = PBXs? Should we deprecate offer-less INVITEs, even from 3PCC servers, = for example? (fwiw, I'd be ok with doing that :) Lastly, this is the type of feature-creep that makes things harder to = specify, implement, and deploy, instead of focusing on the problem at = hand. =20 -hadriel On Jun 27, 2013, at 4:06 PM, "Peterson, Jon" = wrote: >=20 > There are some areas of ambiguity here, definitely, about the scope of > RFC4474 against the current work. A lot of this comes down to = questions > we've discussed before: dealing with non-INVITE requests and defining = the > threat of impersonation properly. If, extending the analogy to email, = you > could secure the =46rom header but not the body of the message, would = it be > "impersonation" when someone changed the message body so that it = appeared > you were saying something different than you intended? >=20 > We agreed coming in to this to scope the threat model such that a > man-in-the-middle modifying SDP, for example, changing m=3D or c=3D = lines, > would not break the signature protecting caller ID. Personally, I = think > there is value for impersonation protection in some environments and > scenarios in detecting change in message bodies - for non-INVITE = requests > (MESSAGE, say), protecting security parameters in SDP which support = SRTP, > etc. I think there are ways to design the overall mechanism that can > reconcile those two requirements. Some kind of separate signature over = the > body, where the body signature would be optionally added by the > authentication service, is something we've discussed before. Maybe = there > should be a special case for parameters relevant to SRTP. I don't = think we > need a fully-baked solution at this point, but yes, I'd want that to = be > part of the discussion of where we go with any identity mechanism for = SIP. >=20 > Moreover, loosening the threat model when it comes to = men-in-the-middle > doesn't mean we should ignore replay attacks. When you say "caller-id = for > a given request, and nothing more," taken literally that would = probably > fall short of the bar of protecting against cut-and-paste attacks. So = no, > I don't think it's reasonable to say the scope of this is protecting = only > the calling party number. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/27/13 12:14 PM, "Hadriel Kaplan" = wrote: >=20 >>=20 >> On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" = >> wrote: >>=20 >>> - The charter should be clear that we intend to obsolete RFC4474 and >>> replace it with something, regardless of whether or not that happens = to >>> be >>> one of our current input drafts. >>=20 >> It's likely that the resulting outcome of this WG ends up being a = much >> narrower assertion of stuff being protected/authenticated - in >> particular, it might only end up protecting the caller-id for a given >> request, and nothing more. ISTM that rfc4474 tried to 'protect' = things >> that went beyond simply the caller-id of a request. So if we *only* >> protect the caller-id, will you be comfortable with replacing = RFC4474? >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From wilhelm@wimmreuter.de Thu Jun 27 15:07: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 D4F9B21F999C for ; Thu, 27 Jun 2013 15:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w3TMk5NWJA7 for ; Thu, 27 Jun 2013 15:07:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id EDEA721F998B for ; Thu, 27 Jun 2013 15:07:35 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M9tU4-1Uytv445Xs-00BJdA; Fri, 28 Jun 2013 00:07:35 +0200 Received: by wwnet.ww (Postfix, from userid 783) id DFFCD10098F; Fri, 28 Jun 2013 00:07:33 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id E863E100311; Fri, 28 Jun 2013 00:07:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Fri, 28 Jun 2013 00:07:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:JS6vl4lp+C4ABFW6NVhF6nE/rK6Ps8qQgj4bgZRUiyj 3aRwODJMGxAb6MAH/pRo8D1z9KKZbjFrU1b2AbT79aouvD+x7W 55geW++As1zBoYplbwXvDGAdXUvykO0OfY8fpERKAhqJlczzAR 6rXgkfWptBBTHsmEQXWL4YIc4zfeNlvJuZAEMlr96m32W54vpI 3WtY5CrDucLayNOMjWR13y2tmG3vbGQAbbQzTDXE8DypdMwOnv Xq07/cTb+KfuWS8n7rz0Q/Pq3qxMHb0a58pIfRC8p6LEpQOjgI +E/UkIHz3EcJKnhulEbeMMxKh9xh/kcq2BW2fLvmScFFUJJZU6 djD5kyBUiPxU0cpumTTXIrqVGKmZM1mNG9N0RsVTv Cc: "stir@ietf.org" , Hadriel Kaplan , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 27 Jun 2013 22:07:56 -0000 Guess it is pretty hard do design the "all singi'n & dancing machine" = here ;-) RFC4474 tried and struggled across modified headers and other neat = things. Why not start with a mandatory Caller-ID in the digest? This approach = will at least prevent the majority of spoofing since the signed = Caller-ID can be validated against a public CA. ... of course this will not prevent MITM Copy and Paste or = biting-attacks which are a minority and thus we can ignore it for the = start. This will however reveal all these script kiddies acting at the = origin. I guess this is the majority of all spoofing attacks. For all other cases we need to think a bit further. Optional steps could sign unmodified headers, time-stamps and random = identifiers that could reveal MITM modifications.=20 Out of band databases to temporarily store enforceable-tokens for each = call instance can be an additional way to validate regardless of = anything that was modified on the way to the validating entity or even = in the endpoint. Willi On 27.06.2013, at 22:06, Peterson, Jon wrote: >=20 > There are some areas of ambiguity here, definitely, about the scope of > RFC4474 against the current work. A lot of this comes down to = questions > we've discussed before: dealing with non-INVITE requests and defining = the > threat of impersonation properly. If, extending the analogy to email, = you > could secure the =46rom header but not the body of the message, would = it be > "impersonation" when someone changed the message body so that it = appeared > you were saying something different than you intended? >=20 > We agreed coming in to this to scope the threat model such that a > man-in-the-middle modifying SDP, for example, changing m=3D or c=3D = lines, > would not break the signature protecting caller ID. Personally, I = think > there is value for impersonation protection in some environments and > scenarios in detecting change in message bodies - for non-INVITE = requests > (MESSAGE, say), protecting security parameters in SDP which support = SRTP, > etc. I think there are ways to design the overall mechanism that can > reconcile those two requirements. Some kind of separate signature over = the > body, where the body signature would be optionally added by the > authentication service, is something we've discussed before. Maybe = there > should be a special case for parameters relevant to SRTP. I don't = think we > need a fully-baked solution at this point, but yes, I'd want that to = be > part of the discussion of where we go with any identity mechanism for = SIP. >=20 > Moreover, loosening the threat model when it comes to = men-in-the-middle > doesn't mean we should ignore replay attacks. When you say "caller-id = for > a given request, and nothing more," taken literally that would = probably > fall short of the bar of protecting against cut-and-paste attacks. So = no, > I don't think it's reasonable to say the scope of this is protecting = only > the calling party number. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/27/13 12:14 PM, "Hadriel Kaplan" = wrote: >=20 >>=20 >> On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" = >> wrote: >>=20 >>> - The charter should be clear that we intend to obsolete RFC4474 and >>> replace it with something, regardless of whether or not that happens = to >>> be >>> one of our current input drafts. >>=20 >> It's likely that the resulting outcome of this WG ends up being a = much >> narrower assertion of stuff being protected/authenticated - in >> particular, it might only end up protecting the caller-id for a given >> request, and nothing more. ISTM that rfc4474 tried to 'protect' = things >> that went beyond simply the caller-id of a request. So if we *only* >> protect the caller-id, will you be comfortable with replacing = RFC4474? >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From dhc@dcrocker.net Thu Jun 27 15:56: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 D88A811E8118 for ; Thu, 27 Jun 2013 15:56:50 -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 DLOcBG5LscHO for ; Thu, 27 Jun 2013 15:56:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCF11E8115 for ; Thu, 27 Jun 2013 15:56:45 -0700 (PDT) Received: from [192.168.1.116] (99-150-245-122.lightspeed.sndgca.sbcglobal.net [99.150.245.122]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5RMuXaO027410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 15:56:43 -0700 Message-ID: <51CCC31A.6000904@dcrocker.net> Date: Thu, 27 Jun 2013 15:56: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: "Peterson, Jon" 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, 27 Jun 2013 15:56:45 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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: Thu, 27 Jun 2013 22:56:51 -0000 On 6/27/2013 10:48 AM, Peterson, Jon wrote: > - The potential interpretation of "the entity formally assigned use of > that number." That can be read in a number of ways, some of which will > close doors that need to remain open, I think. There are multiple > assignments that take place, from the ITU-T down to national regulators, > from regulators to carriers, from carriers to end users, with various Everyone you cite, except "end users" are not "users" of the numbers. They are administrators of registries and other providers of infrastructure support for the number. That, at least, was the distinction I meant to draw by saying "use". The group agreed to say "assignee" rather than "owner" and that's who is meant by the text's use of "assigned". If some other verbiage will more robustly ensure that the reader knows, essentially, that the reference is meant to be whoever answers the phone at that number, please suggest it. No doubt, some signers will be telcos or other operators, and this might seem confusing, but they are doing it /on behalf of/ the end user. Even if real end users happen not to know their calls are being protected with a signature on their behalf, it is on their behalf. It's not "by" the operator. They are a delegate of the user. > resellers and enterprises stuck in the middle. Is one of these assignments > formal and the others not, or are all of them potentially in play? To > leave open possibilities, I might gloss over this with "an entity assigned > use of the number." Given the ambiguity you've cited, I strongly suggest that the charter language /not/ gloss over any reasonable misunderstanding. Let's get the language as tight and clear as we can. > - The deliverable for "the means of obtaining security-related parametric > information." The literal means of obtaining keys/credentials, I think, > are in the scope of the authorization validation method deliverable - for > RFC4474, for example, this was the Identity-Info header and the URI > schemes it described. You certainly can't do authorization validation > without that means. I could read this deliverable as if it's suggesting > that header or mechanism should be in a separate document. The original > charter had "key management" as a separate deliverable, which is a > slightly different scope. > > - The charter should be clear that we intend to obsolete RFC4474 and > replace it with something, regardless of whether or not that happens to be > one of our current input drafts. I see a separate sub-thread happening on this, so I'll wait to modify draft charter text until that's resolved. FWIW, my own reading of RFC4474 causes me to think that dealing with it for the current effort will primarily add confusion rather than benefit, especially since it has a broader scope and it appears to have no meaningful deployment this many years after IETF approval. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Jun 27 16:43: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 5DA3E11E8112 for ; Thu, 27 Jun 2013 16:43:50 -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 v1vxdJRxU5FT for ; Thu, 27 Jun 2013 16:43:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0BDB11E8104 for ; Thu, 27 Jun 2013 16:43:45 -0700 (PDT) Received: from [192.168.1.116] (99-150-245-122.lightspeed.sndgca.sbcglobal.net [99.150.245.122]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5RNhawD028068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 16:43:39 -0700 Message-ID: <51CCCE21.1030008@dcrocker.net> Date: Thu, 27 Jun 2013 16:43:29 -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: <51CC4ED6.30408@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, 27 Jun 2013 16:43:40 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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: Thu, 27 Jun 2013 23:43:50 -0000 On 6/27/2013 2:20 PM, Russ Housley wrote: > Dave: > > Thanks for proposing text. There are places where there is obvious > improvement, but there are other places that raise concern for me. > Comments below. { blanket disclaimer about my responses [1] /d } >> As with email, the claimed source identity of a SIP request (in the >> From field) is not verified. As with email, this permits and >> produces unauthorized use of source identities as part of deceptive >> and coercive activities, such as bulk unsolicited commercial >> communications, voicemail hacking, and impersonating banks. The >> current effort will specify a mechanism to support validation that >> a telephone number's presence in the SIP From field is authorized >> by the entity formally assigned use of that number, or by their >> delegate. The mechanism will support end-to-end SIP interactions. >> Initial specification will be in terms of a pure-SIP exchange, >> which will serve as the operational base. Additional mechanisms >> might later be developed to support more complicated mediation >> scenarios. > > I do not think "As with email" helps in the first two sentences. SIP > is a fairly well understood protocol in the IETF, so we can just talk > about it. Well.... I suggest that this isn't about "SIP" as much as it is about "protecting" SIP and that's something quite different, in terms of people's experience. (I guarantee you that 'protecting' email was a very, very different engineering exercise for me than was creating basic email protocol functions. SIP is not the first service worrying about a large-scale forgery problem. The reference to email is meant to class the problem domain as one that we've actually got quite a lot of experience with, in terms of threats and attackers and engineering a response to them. In addition, it happens that in very broad terms, the approach being proposed here is quite similar to one the IETF has already standardized. (I said "broad". I said "very".) So my feeling is that it helps to start a new effort by noting its similarity to one that has already been pursued in the IETF and that has quite a lot of operational experience. > The last sentence is confusing to me. The previous sentences say > that the WG will develop a mechanism, and then the last sentence > calls for additional ones in "complicated mediation scenarios". > Since mediation has not come up in this text before, I am not sure > what it means here. Hmmm. "end-to-end SIP" and "pure SIP" are meant to indicate a highly simplified underlying protocol scenario, for the current round of effort. Obviously things are, and will be, more complicated, with hybrid scenarios. I meant to hint at those, to acknowledge them and to exclude them. For the first paragraph that seems like enough. But I take your point that the last sentence lacks transition/introduction. Perhaps: Because SIP is often used in complex, hybrid scenarios in which it is not the only protocol, additional mechanisms might later be developed to augment the pure-SIP mechanism. >> The working group will consider choices for the method of >> specifying authorization information and the means of obtaining the >> parametric information needed to perform that authorization check. >> An example of the first could be use of a >> cryptographically-protected field carried by SIP and containing >> identity and authentication information. An example of the second >> could be a mechanism for querying an external database, to obtain >> the key-signing parameters for the authentication cryptography. > > I suggest this should be higher level description. I suggest: > > The working group will consider choices for the method of specifying > authorization information and the means of authenticating and > validating this information. For example, a > cryptographically-protected field carried by SIP could contain > identity and authentication information, and then a database could be > queried to obtain the keying material to perform the authentication > checking. wfm. { I had thought the text you replaced was pretty high level, but no matter; yours reads better to me. } >> A number of previous efforts have attacked the problem of securing >> the origins of SIP communications, including RFC3325, RFC4474 and >> the VIPR working group. To date, however, true validation of the >> source of SIP calls has not seen any appreciable deployment. While >> several factors contributed to this lack of success, culprits >> included: failure of the problem to be seen as critical at the >> time; lack of any real means of asserting authority over telephone >> numbers on the Internet; misalignment of the mechanisms proposed >> by RFC4474 with the complex deployment environment that has emerged >> for SIP; and inherent operational problems with a transitive trust >> model. > > All good. Perhaps a sentence about why we think the time is better > now would complete this thought. uhhh... sure. Feed me. >> 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 >> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >> >> Secure Origin Identification: Problem Statement, Requirements, and >> Roadmap >> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >> >> Authenticated Identity Management in the Session Initiation >> Protocol (SIP) >> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 > > Others has suggested that this is important for these to be available > to BOF participants, but several people have suggested removing it > from the charter. > > I think that the problem statement could remain, but if other object, > I an not hard over on it. Wasn't sure how much of the existing input docs to cite. Charters vary on this. I'll take your directions as removing all but problem statement. >> A likely approach for SIP-based authorization validation is to >> include a new capability for Identity assertions to cover telephone >> numbers, rather than domain names. To conform with realistic >> deployments. > > I'd like to see the same rigor that you used earlier applied to this > paragraph. I think the mechanism and validation are not clearly > separated in this description. well, ummm, I was trying to preserve as much of the original draft text as I could... On reflection, given where the group's discussion has gone, the reference to domain names is now probably vestigial and unhelpful. Perhaps: A likely approach for SIP source identity validation will be to employ a cryptographically-protected Identity assertion accompanying the telephone number in the SIP From field. An external query service is likely to be defined for obtaining the necessary cryptography-related parameters. { no, I'm not in love with it either. again... feed me. } > >> The working group will coordinate with the security area, for any >> proposal details that utilize classic security mechanisms, such as >> cryptography and certificate credentials. >> >> The working group will coordinate with RAI area groups studying >> the problem of signaling through existing deployments, including >> activities in the INSIPID and STRAW working groups. >> >> Identity is closely linked to privacy, and frequently one comes at >> the cost of the other. To the extent feasible the working group >> will favor privacy-friendly choices that minimize call information >> leakage to third parties. >> >> The working group will deliver the following: >> >> - Problem statement detailing the deployment environment and >> difficulties motivating work on secure origins > > Maybe the starting point of draft-cooper-iab-secure-origin-00 goes > here. Stylistically, I'm used to having "input" stuff in a charter precede "deliverable" stuff. But that's a nit, of course. >> - Specification of an authorization validation method for the >> source telephone number identity of a SIP request (in the From >> field) >> >> - Specification of the means for obtaining security-related >> parametric information, used to perform source telephone number >> identity authorization validation. > > I think that the last deliverable should focus on the validation of > the authorization information. Yes, we will have to specify all the > steps, but the description should not already assume that not > inserted by the caller. Hmmm. I was trying to distinguish between the basic 'packaging' protocol vs. the query service, but I think you are seeing a different distinction. Or perhaps you mean an /additional/ deliverable that combines packaging with query service to produce a complete process for performing validation? Please clarify. I'm not sure what change to make. d/ [1] I'm hoping Russ already knows this, but just to make sure he and everyone else does: I got to 'own' the draft text while writing it and imposing whatever whimsical preferences i felt like; but by posting it to the list, I switched to -- at most -- editor. So I'll offer opinions about suggestions -- and it's the fact that I might get vigorous that prompts my wanting to add this disclaimer -- and am glad to expedite things by assuming what's ok with the group, but it's the group that actually decides on the text. -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Thu Jun 27 16:56: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 1990E11E8145 for ; Thu, 27 Jun 2013 16:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 NKSQGKkJbU5p for ; Thu, 27 Jun 2013 16:56: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 89AB411E8104 for ; Thu, 27 Jun 2013 16:56:42 -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, 27 Jun 2013 16:56:38 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" , "housley@vigilsec.com" Thread-Topic: [stir] Revised charter text for STIR Thread-Index: AQHOc0RMQjpB2TraA0SWDVW5gXHhNZlKhyYAgAAn6oD//4yMkA== Date: Thu, 27 Jun 2013 23:56:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0E654@EX2K10MB1.corp.yaanatech.com> References: <51CC4ED6.30408@dcrocker.net> <51CCCE21.1030008@dcrocker.net> In-Reply-To: <51CCCE21.1030008@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0116_01CE7357.498EB000" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 27 Jun 2013 23:56:47 -0000 ------=_NextPart_000_0116_01CE7357.498EB000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Re: Because SIP is often used in complex, hybrid scenarios in which it is not the only protocol, additional mechanisms might later be developed to augment the pure-SIP mechanism. Maybe: Because SIP is often used in complex, hybrid scenarios in which it is not the only signaling protocol, ancillary signaling mechanisms might later be developed to augment the SIP-only signaling. Signaling could also be replaced by "session-setup protocol", but didn't want to get into the SIP versus SDP and which is really session stuff. Mechanisms seemed a bit broad. Just wanted to suggest that it is the "call" signaling aspect of the networks that we are focused on. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Thursday, June 27, 2013 4:43 PM To: Russ Housley Cc: stir@ietf.org Subject: Re: [stir] Revised charter text for STIR On 6/27/2013 2:20 PM, Russ Housley wrote: > Dave: > > Thanks for proposing text. There are places where there is obvious > improvement, but there are other places that raise concern for me. > Comments below. { blanket disclaimer about my responses [1] /d } >> As with email, the claimed source identity of a SIP request (in the >> From field) is not verified. As with email, this permits and produces >> unauthorized use of source identities as part of deceptive and >> coercive activities, such as bulk unsolicited commercial >> communications, voicemail hacking, and impersonating banks. The >> current effort will specify a mechanism to support validation that a >> telephone number's presence in the SIP From field is authorized by >> the entity formally assigned use of that number, or by their >> delegate. The mechanism will support end-to-end SIP interactions. >> Initial specification will be in terms of a pure-SIP exchange, which >> will serve as the operational base. Additional mechanisms might later >> be developed to support more complicated mediation scenarios. > > I do not think "As with email" helps in the first two sentences. SIP > is a fairly well understood protocol in the IETF, so we can just talk > about it. Well.... I suggest that this isn't about "SIP" as much as it is about "protecting" SIP and that's something quite different, in terms of people's experience. (I guarantee you that 'protecting' email was a very, very different engineering exercise for me than was creating basic email protocol functions. SIP is not the first service worrying about a large-scale forgery problem. The reference to email is meant to class the problem domain as one that we've actually got quite a lot of experience with, in terms of threats and attackers and engineering a response to them. In addition, it happens that in very broad terms, the approach being proposed here is quite similar to one the IETF has already standardized. (I said "broad". I said "very".) So my feeling is that it helps to start a new effort by noting its similarity to one that has already been pursued in the IETF and that has quite a lot of operational experience. > The last sentence is confusing to me. The previous sentences say that > the WG will develop a mechanism, and then the last sentence calls for > additional ones in "complicated mediation scenarios". > Since mediation has not come up in this text before, I am not sure > what it means here. Hmmm. "end-to-end SIP" and "pure SIP" are meant to indicate a highly simplified underlying protocol scenario, for the current round of effort. Obviously things are, and will be, more complicated, with hybrid scenarios. I meant to hint at those, to acknowledge them and to exclude them. For the first paragraph that seems like enough. But I take your point that the last sentence lacks transition/introduction. Perhaps: Because SIP is often used in complex, hybrid scenarios in which it is not the only protocol, additional mechanisms might later be developed to augment the pure-SIP mechanism. >> The working group will consider choices for the method of specifying >> authorization information and the means of obtaining the parametric >> information needed to perform that authorization check. >> An example of the first could be use of a cryptographically-protected >> field carried by SIP and containing identity and authentication >> information. An example of the second could be a mechanism for >> querying an external database, to obtain the key-signing parameters >> for the authentication cryptography. > > I suggest this should be higher level description. I suggest: > > The working group will consider choices for the method of specifying > authorization information and the means of authenticating and > validating this information. For example, a > cryptographically-protected field carried by SIP could contain > identity and authentication information, and then a database could be > queried to obtain the keying material to perform the authentication > checking. wfm. { I had thought the text you replaced was pretty high level, but no matter; yours reads better to me. } >> A number of previous efforts have attacked the problem of securing >> the origins of SIP communications, including RFC3325, RFC4474 and >> the VIPR working group. To date, however, true validation of the >> source of SIP calls has not seen any appreciable deployment. While >> several factors contributed to this lack of success, culprits >> included: failure of the problem to be seen as critical at the time; >> lack of any real means of asserting authority over telephone numbers >> on the Internet; misalignment of the mechanisms proposed by RFC4474 >> with the complex deployment environment that has emerged for SIP; and >> inherent operational problems with a transitive trust model. > > All good. Perhaps a sentence about why we think the time is better > now would complete this thought. uhhh... sure. Feed me. >> 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 >> http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00 >> >> Secure Origin Identification: Problem Statement, Requirements, and >> Roadmap >> http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00 >> >> Authenticated Identity Management in the Session Initiation Protocol >> (SIP) >> http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00 > > Others has suggested that this is important for these to be available > to BOF participants, but several people have suggested removing it > from the charter. > > I think that the problem statement could remain, but if other object, > I an not hard over on it. Wasn't sure how much of the existing input docs to cite. Charters vary on this. I'll take your directions as removing all but problem statement. >> A likely approach for SIP-based authorization validation is to >> include a new capability for Identity assertions to cover telephone >> numbers, rather than domain names. To conform with realistic >> deployments. > > I'd like to see the same rigor that you used earlier applied to this > paragraph. I think the mechanism and validation are not clearly > separated in this description. well, ummm, I was trying to preserve as much of the original draft text as I could... On reflection, given where the group's discussion has gone, the reference to domain names is now probably vestigial and unhelpful. Perhaps: A likely approach for SIP source identity validation will be to employ a cryptographically-protected Identity assertion accompanying the telephone number in the SIP From field. An external query service is likely to be defined for obtaining the necessary cryptography-related parameters. { no, I'm not in love with it either. again... feed me. } > >> The working group will coordinate with the security area, for any >> proposal details that utilize classic security mechanisms, such as >> cryptography and certificate credentials. >> >> The working group will coordinate with RAI area groups studying the >> problem of signaling through existing deployments, including >> activities in the INSIPID and STRAW working groups. >> >> Identity is closely linked to privacy, and frequently one comes at >> the cost of the other. To the extent feasible the working group will >> favor privacy-friendly choices that minimize call information >> leakage to third parties. >> >> The working group will deliver the following: >> >> - Problem statement detailing the deployment environment and >> difficulties motivating work on secure origins > > Maybe the starting point of draft-cooper-iab-secure-origin-00 goes > here. Stylistically, I'm used to having "input" stuff in a charter precede "deliverable" stuff. But that's a nit, of course. >> - Specification of an authorization validation method for the source >> telephone number identity of a SIP request (in the From >> field) >> >> - Specification of the means for obtaining security-related >> parametric information, used to perform source telephone number >> identity authorization validation. > > I think that the last deliverable should focus on the validation of > the authorization information. Yes, we will have to specify all the > steps, but the description should not already assume that not inserted > by the caller. Hmmm. I was trying to distinguish between the basic 'packaging' protocol vs. the query service, but I think you are seeing a different distinction. Or perhaps you mean an /additional/ deliverable that combines packaging with query service to produce a complete process for performing validation? Please clarify. I'm not sure what change to make. d/ [1] I'm hoping Russ already knows this, but just to make sure he and everyone else does: I got to 'own' the draft text while writing it and imposing whatever whimsical preferences i felt like; but by posting it to the list, I switched to -- at most -- editor. So I'll offer opinions about suggestions -- and it's the fact that I might get vigorous that prompts my wanting to add this disclaimer -- and am glad to expedite things by assuming what's ok with the group, but it's the group that actually decides on the text. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0116_01CE7357.498EB000 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy NzIzNTYzN1owIwYJKoZIhvcNAQkEMRYEFL0iNWYpd7i5tvfls7nLIRbEPVf2MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFFNafb5ah35gE+0qM+NNlvZEd9HPWYmH+otBAuaQ VnluDXAvmOVikjCV0zNP2cex2awn0MQm33lJSmn7ptp5sxx8QNL4ijPjWWy8ScXNgz6l/DL4orzJ InTPM3hV8u8QUAnXUW4BmsGv4k3jsKPlXq38ZNWmnqG2mzn1Y18H7xz+NurI+Ee+PtO9aX5q3DQL anbcwHuew91QEPQE+GptcNYI336OoSPXgSw+bG1SH5H7vzBeUETZPx8eJiWkxESvychlN8fg8gnQ VY3UU/enTjxDPh9sPVyulnDSM+nlx1DQPxuBZSOuJNh6A0cIiyl71Or3Vf6lIBz9yAdQpnXJqwAA AAAAAA== ------=_NextPart_000_0116_01CE7357.498EB000-- From jon.peterson@neustar.biz Thu Jun 27 17:03: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 0F12A11E8146 for ; Thu, 27 Jun 2013 17:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 9+k3UtbxFqob for ; Thu, 27 Jun 2013 17:03:55 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C40DF11E8147 for ; Thu, 27 Jun 2013 17:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372378329; x=1687736173; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=pERMrbDnXy wY4zvrgAxic07ykdHNg48s5xIQ6o39tNc=; b=eNd61ZwVRVjz776IxQV8BgOiH0 zNWysBlwbzxDEQ4GB5C4vl4KtBW8ReGBSTMqczi3tCKfRA1nhl9K2RvtmqiA== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26997192; Thu, 27 Jun 2013 20:12:08 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 20:03:44 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlJylwAgACW4AD//6uKAA== Date: Fri, 28 Jun 2013 00:03:44 +0000 Message-ID: In-Reply-To: <1F10D3A5-D2C8-4088-A80E-4683822C5B1E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: V6D6rpLBnMostJ9ZYSPAjw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 00:03:59 -0000 On 6/27/13 3:06 PM, "Hadriel Kaplan" wrote: >Up front I should be clear about one thing: I thought we had been told >that the real-world problem we need to solve and focus on and quickly fix >is bogus/spoofed caller-id. I'm not saying we might not also end up >solving other things simultaneously with the same mechanism, enough so >that we can really replace RFC4474 - I'm just saying we shouldn't be >constrained to having to do so by putting it in the charter right now. >It might turn out we can replace 4474, but we don't know that yet. Maybe we should postpone that question to after chartering, but if we can't agree on how close the scope of security services is to what RFC4474 offers, that may actually be a charter-level problem. Scope as in, that it not be susceptible to replay attacks, say. >I agree that we could come up with some way to provide optional >protection for the SDP or parts thereof, even with the ability to verify >the caller-id while failing to verify the SDP all with one signature. >The problem is it wouldn't be of any use. It gets back to the notion of >there being different levels of security - shades of gray - that somehow >users could distinguish between somewhat-secure and somewhat-more-secure >calls. I think there are already a set of discernible and different security properties of a SIP session. For example, you raise one below, whether the media uses SRTP or not. If a call uses identity, we could say it is somewhat secure, and if it also uses SRTP, we could say its somewhat-more-secure. You seem to be arguing that if there are two distinct security properties, the question of how to render them in the UI trumps any inherent usefulness in their deployment? Is SRTP only useful if a UI is telling you it's there? Certainly there are times you might want to be sure SRTP is in place, and in those times users should have a way to check it. Similarly, there might be times you really want to make sure that the number calling you is unspoofed, and if the surety isn't there, you may change your behavior. I'm not afraid offering information to SIP entities without designing an algorithm that reduces every factor to a single binary lockbox graphic. >And the truth is it would only be "somewhat-more-secure", not actually >"secure", for the same reasons that using DTLS-SRTP doesn't truly provide >"secure" end-to-end media even in WebRTC. You'd need an out-of-band, >real endpoint-to-endpoint, trusted-third-party assurance model for that; >something like EKR's IdP proposal for WebRTC might get close, for >example. But if you have some out-of-band mechanism, then you don't need >a STIR in-band mechanism to protect the SDP at all - it's superfluous. Even trying to apply a blanket term like "secure" to something as manifold and complex as a SIP session is problematic. Again, there are little chunks of problem and of solution scattered through the specs. And broadly, agreed that out-of-band can do more interesting things than in-band, but as you know it has its own challenges to overcome. >Furthermore, I think most people here agree that the SDP-portion would >change virtually all the time today, which means that that part of the >assertion will fail all the time today. So adding that portion is >useless today, if not outright counter-productive to getting STIR >adopted. So skip forward to the future, at some point the extra >assertion might start succeeding on a few calls somewhere. Then what? >Do you start rejecting calls that don't succeed at it? Even if most >calls succeed with it, do you reject the rest? What is this >distinguishing security assertion useful for, to either machines or >humans? I'm not necessarily saying that body-level security should be an all-or-nothing thing like it was in RFC4474, at least not for INVITE requests - it might be possible to design something helpful that wouldn't even fail in some deployments similar to the ones you have in mind. RFC4474 opted to do the simplest thing we could think of, which was to treat all requests alike and to offer the same protection to all message bodies. It was thinking about NOTIFYs and MESSAGEs as well as INVITEs. Perhaps today we'd approach it differently. But more materially, I am proposing that we create an optional hook for the deployments and scenarios where protecting some elements of bodies makes sense. I fully understand that there are deployments where it will not be practical, and I think we can make the hook quite unobtrusive for those deployments. My question to you is, are you so dedicated to the architecture of SIP request bodies being unprotected that you're unwilling to have even an option for this? >So let's talk about the replay and cut-and-paste attack scenarios. Let's >assume we all agreed we need to prevent them - since we know the SDP >portion of the assertion will fail most of the time today, shouldn't we >be trying to prevent them regardless of the SDP being changed or not by >transit domains, so that we can protect the caller-id from such an attack >today? There is a very popular Enterprise PBX vendor that by-default >sends INVITEs without SDP - are we saying calls from those PBXs can't >have their caller-id's protected as strongly as from other PBXs? Should >we deprecate offer-less INVITEs, even from 3PCC servers, for example? >(fwiw, I'd be ok with doing that :) I'm not sure why you're linking replay protection and body protection here - I didn't suggest they were connected in my mail. Replay protection is really a question of what headers are going to get signed. As I sent in a mail very early in the list, I didn't think from what I read in your draft that we're hugely far apart on this. >Lastly, this is the type of feature-creep that makes things harder to >specify, implement, and deploy, instead of focusing on the problem at >hand.=20 If by "this" you mean "replay protection," I'd say it is something that makes this actually prevent impersonation instead of not preventing impersonation. Jon Peterson Neustar, Inc. >-hadriel > > >On Jun 27, 2013, at 4:06 PM, "Peterson, Jon" >wrote: > >>=20 >> There are some areas of ambiguity here, definitely, about the scope of >> RFC4474 against the current work. A lot of this comes down to questions >> we've discussed before: dealing with non-INVITE requests and defining >>the >> threat of impersonation properly. If, extending the analogy to email, >>you >> could secure the From header but not the body of the message, would it >>be >> "impersonation" when someone changed the message body so that it >>appeared >> you were saying something different than you intended? >>=20 >> We agreed coming in to this to scope the threat model such that a >> man-in-the-middle modifying SDP, for example, changing m=3D or c=3D line= s, >> would not break the signature protecting caller ID. Personally, I think >> there is value for impersonation protection in some environments and >> scenarios in detecting change in message bodies - for non-INVITE >>requests >> (MESSAGE, say), protecting security parameters in SDP which support >>SRTP, >> etc. I think there are ways to design the overall mechanism that can >> reconcile those two requirements. Some kind of separate signature over >>the >> body, where the body signature would be optionally added by the >> authentication service, is something we've discussed before. Maybe there >> should be a special case for parameters relevant to SRTP. I don't think >>we >> need a fully-baked solution at this point, but yes, I'd want that to be >> part of the discussion of where we go with any identity mechanism for >>SIP. >>=20 >> Moreover, loosening the threat model when it comes to men-in-the-middle >> doesn't mean we should ignore replay attacks. When you say "caller-id >>for >> a given request, and nothing more," taken literally that would probably >> fall short of the bar of protecting against cut-and-paste attacks. So >>no, >> I don't think it's reasonable to say the scope of this is protecting >>only >> the calling party number. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 6/27/13 12:14 PM, "Hadriel Kaplan" wrote: >>=20 >>>=20 >>> On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" >>> wrote: >>>=20 >>>> - The charter should be clear that we intend to obsolete RFC4474 and >>>> replace it with something, regardless of whether or not that happens >>>>to >>>> be >>>> one of our current input drafts. >>>=20 >>> It's likely that the resulting outcome of this WG ends up being a much >>> narrower assertion of stuff being protected/authenticated - in >>> particular, it might only end up protecting the caller-id for a given >>> request, and nothing more. ISTM that rfc4474 tried to 'protect' things >>> that went beyond simply the caller-id of a request. So if we *only* >>> protect the caller-id, will you be comfortable with replacing RFC4474? >>>=20 >>> -hadriel >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From jon.peterson@neustar.biz Thu Jun 27 17:11: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 BC90611E8167 for ; Thu, 27 Jun 2013 17:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 6bxJUKWSDHkg for ; Thu, 27 Jun 2013 17:11:34 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B9CAD11E815B for ; Thu, 27 Jun 2013 17:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372378785; x=1687736173; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=y0i4Futobn 2GjOTaH5yhrR0/gFIEUZEYSLcHjEn1MaY=; b=CT0h2TVmVWv3A/3e9Tr1wP3iAY 7mDPgDHVJ/tXo6RTRum0LHHzrF5l/c/Alu21XnEu6nWvyr4msKKO6AGQJDqw== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26997427; Thu, 27 Jun 2013 20:19:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 20:11:22 -0400 From: "Peterson, Jon" To: Michael Hammer , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnbsMmZQTrk9EapAINY/F31vZk+4muAgAAHWYCAACgJgIABI2sAgACC9gCABJqygIAA53gAgABygoCAACfSAIAACiiAgAAVTgCAAAL9AIAAIBoAgADZkICAAF9KAIAAA26AgACLhoCAAAMNAIAACYQAgAAqmgCAAC/OAIAAvjyAgAAOJwD//6URAIAAsdKA//+xQQA= Date: Fri, 28 Jun 2013 00:11:21 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: By7HBnQv84MsLv+iEJs9ow== Content-Type: text/plain; charset="us-ascii" Content-ID: <7BC3386F069E2E45A0D25CD31D9C1065@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 00:11:37 -0000 >Agree. But, I may be looking for something a little more stringent. > >First, you have to have a string that has a canonical form. >If it is not, then the string is likely something out of scope. Not sure what you mean. >Second, you have to have a place in a header that you can be guaranteed to >find that canonical form. No, actually, I think the idea is just the opposite, that the canonical form would not appear as a literal in the message. Both the auth service and the verification service must have an algorithm that will let them derive the (single identical) canonical form from what they find in the From, however scungy it may be. >We seem to be very squishy about that. I don't want to have to know the >secret hand-shake to understand that. Secret handshakes are to be avoided, yes. >(Standard versus clubs) A recipient should not have to have a different >flavor or handling for aaa.com or bbb.com, or ... >Note, what someone does intra-domain may not matter. At least at the >inter-domain boundary, be standard. > >Third, if the normal rules state that the context of a string is defined >by >a domain and not by the standard, and, >since you have previously stated (I think) that the domain can do whatever >it wants with the user part, >then I really can't know that any user part string is an E.164 or >something >else. >So, if it is within the scope of a domain, all bets are off. It is just an assumption of this model that the canonicalization is possible. Clearly it is conceivable that a verification service will receive a From and be unable to canonicalize the contents of its user part into a valid telephone number - that would be an identity failure. If intermediary systems cause that to happen, their policies would have to change for identity to be possible. >The degree of flexibility you want to preserve is probably directly >proportional to the degree of non-interoperability you will get. The only thing this is trying to preserve is interoperability with existing systems that rely on the From. Jon Peterson Neustar, Inc. > >Mike > > >-----Original Message----- >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Thursday, June 27, 2013 11:17 AM >To: Hadriel Kaplan; Michael Hammer >Cc: stir@ietf.org; dcrocker@bbiw.net >Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > >>It does not matter if it started as 'sip:5551212@aaa.com;user=3Dphone' >>and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >>terminator uses it as the E.164 phone number '12125551212' in his >>systems and caller-id displays, then what he really needs to know is >>that this call request came from someone with the authority to claim >>'12125551212' - he does *not* need to know it really came from >>'bbb.com', nor that it came from user '+1-212-555-1212', nor even that it >came from SIP. > >Perhaps what some folks are missing here is the clear statement that both >the auth service and the verification service need to canonicalize the >From >number to E.164 (actually a bit of a variant, but glossing over for >now) as a part of the signature generation/verification process. > >The idea is basically this: when the auth signature is placed over >sip:5551212@aaa.com, the auth service canonicalizes 5551212 to >"12125551212", and that is what is signed over in the digest-strig of the >Identity header. In RFC4474 terms, this canonicalized string would take >the >place of the addr-spec of the AoR in Section 9. When the verification >service receives +1-212-555-1212@bbb.com, it too canonicalizes that to >12125551212 for the purposes of regenerating the digest-string. Thus it >doesn't matter how From is munged. Nor do you need to store a copy of the >number anywhere in the message, which for the various reasons previously >discussed won't work. > >The requirement here that both the auth service and verification service >canonicalize numbers in the same fashion is absolute, and perhaps >non-trivial, but it's certainly way better than hop-by-hop protection. > >Jon Peterson >Neustar, Inc. > From pkyzivat@alum.mit.edu Thu Jun 27 17:20: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 90BC421F93E5 for ; Thu, 27 Jun 2013 17:20:24 -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 SZNZG4hMXDyy for ; Thu, 27 Jun 2013 17:20:20 -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 48F9A21F93D4 for ; Thu, 27 Jun 2013 17:20:20 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id tbPS1l0040QuhwU5BcLHnp; Fri, 28 Jun 2013 00:20:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id tcLH1l00b3ZTu2S3NcLH4B; Fri, 28 Jun 2013 00:20:17 +0000 Message-ID: <51CCD6C0.7050108@alum.mit.edu> Date: Thu, 27 Jun 2013 20:20:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stir@ietf.org References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@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=1372378817; bh=b3srQN/ZClf/1BkpmYrc1z9wLdX5V9qOkUTl/9Co8zE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HO9ExiaUSdqz0lhBYfr8SZYdIZadUQo2nncQgRrS3PGlBBSZ+uRe1bs0dQLu0X2V6 RjW2W9Y5dc+lcI+xJuFOcm0fmKd25I7Mv5BhyCNbZaxUvgDgPQxmOSC2Z9lD7rOahk gKpCmG6APanfFJWvFj5/r4XYz76nDQDj1ZSVXHctdSQF6GcfcVEFgjPJuAI0SQUljf Y8XUFEIGreQZ5coxDco0VaGHSBrdXqcWVALvUQBWlfU5KrbLD0csda6s4+iOE0J31p B5eQPl/imWYwG1G7YfwgB3LOuQg5f5Of2RaiYRXFVmkdDkPfJ9TwuZeAmhqsGd7QnG oL5YIPeXCTWtw== Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 00:20:24 -0000 Mike, On 6/27/13 5:53 PM, Michael Hammer wrote: > Agree. But, I may be looking for something a little more stringent. > > First, you have to have a string that has a canonical form. > If it is not, then the string is likely something out of scope. The presumption is that the strings are whatever is in From and To, and they they *are not* in canonical form. But it is assumed that the signer can look at whatever is in the From and To it sees, and generate a canonical form to sign. And that the verifier can look at whatever is in the From and To *it* sees, and generate the canonical form to verify. And that the get the same result! It is *not* assumed that the signer and the verifier are looking at the identical thing. Each may be looking at a non-canonical form that fits its local conventions, and that magic has resulted in the signer's form being transformed into the verifier's form. It seems to me to be a lousy way to run a railroad, but that is what the deployed systems apparently like to do. Thanks, Paul > Second, you have to have a place in a header that you can be guaranteed to > find that canonical form. > We seem to be very squishy about that. I don't want to have to know the > secret hand-shake to understand that. > (Standard versus clubs) A recipient should not have to have a different > flavor or handling for aaa.com or bbb.com, or ... > Note, what someone does intra-domain may not matter. At least at the > inter-domain boundary, be standard. > > Third, if the normal rules state that the context of a string is defined by > a domain and not by the standard, and, > since you have previously stated (I think) that the domain can do whatever > it wants with the user part, > then I really can't know that any user part string is an E.164 or something > else. > So, if it is within the scope of a domain, all bets are off. > > The degree of flexibility you want to preserve is probably directly > proportional to the degree of non-interoperability you will get. > > Mike > > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, June 27, 2013 11:17 AM > To: Hadriel Kaplan; Michael Hammer > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > >> It does not matter if it started as 'sip:5551212@aaa.com;user=phone' >> and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >> terminator uses it as the E.164 phone number '12125551212' in his >> systems and caller-id displays, then what he really needs to know is >> that this call request came from someone with the authority to claim >> '12125551212' - he does *not* need to know it really came from >> 'bbb.com', nor that it came from user '+1-212-555-1212', nor even that it > came from SIP. > > Perhaps what some folks are missing here is the clear statement that both > the auth service and the verification service need to canonicalize the From > number to E.164 (actually a bit of a variant, but glossing over for > now) as a part of the signature generation/verification process. > > The idea is basically this: when the auth signature is placed over > sip:5551212@aaa.com, the auth service canonicalizes 5551212 to > "12125551212", and that is what is signed over in the digest-strig of the > Identity header. In RFC4474 terms, this canonicalized string would take the > place of the addr-spec of the AoR in Section 9. When the verification > service receives +1-212-555-1212@bbb.com, it too canonicalizes that to > 12125551212 for the purposes of regenerating the digest-string. Thus it > doesn't matter how From is munged. Nor do you need to store a copy of the > number anywhere in the message, which for the various reasons previously > discussed won't work. > > The requirement here that both the auth service and verification service > canonicalize numbers in the same fashion is absolute, and perhaps > non-trivial, but it's certainly way better than hop-by-hop protection. > > Jon Peterson > Neustar, Inc. > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From jon.peterson@neustar.biz Thu Jun 27 17:40: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 EAD2B21F9BF3 for ; Thu, 27 Jun 2013 17:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 6Cw3e1AWz7Q3 for ; Thu, 27 Jun 2013 17:40:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8C21F9BEB for ; Thu, 27 Jun 2013 17:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372380535; x=1687736173; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=O7q/buW/iF gPhMCwLZc16O/hngNQF/1s5esO4/MSl2M=; b=lzZ59e0C6A7ULUMrsBYt9IbpAL IzM33N5nI0eNQIn3Bzl4Hs/QDlVcoO+RcLOk4b+ALmruoyDryOPW4PtBv9Jw== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26998391; Thu, 27 Jun 2013 20:48:54 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 20:40:32 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Revised charter text for STIR Thread-Index: AQHOc0RP7qgb0/rNTkuQHAXjKZBP65lKCYKA//+ayYCAAMtVAP//p7mA Date: Fri, 28 Jun 2013 00:40:32 +0000 Message-ID: In-Reply-To: <51CCC31A.6000904@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.129.80] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uvGWFsa3Sn8Qbq7cfOTepw== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 28 Jun 2013 00:40:57 -0000 [snip] > >No doubt, some signers will be telcos or other operators, and this might >seem confusing, but they are doing it /on behalf of/ the end user. Even >if real end users happen not to know their calls are being protected >with a signature on their behalf, it is on their behalf. It's not "by" >the operator. They are a delegate of the user. I think many people on this list would view telcos signing as the everyday case, and end-user signators as the exception. From an assignment perspective, carriers are certainly not (in contemporary North America anyway) delegates of the user; users are delegates of the carrier. Moreover there are plenty of other actors, like resellers, enterprises, etc who are also delegates and potentially signers. The problem again with the "the entity formally assigned use" language is that it treats the concept of "assignee" as if numbers have a single authority, but the reason "assignee" is a better term here than "owner" is because it doesn't have the connotation that there's some single authority. Numbering doesn't work that way. >> resellers and enterprises stuck in the middle. Is one of these >>assignments >> formal and the others not, or are all of them potentially in play? To >> leave open possibilities, I might gloss over this with "an entity >>assigned >> use of the number." > >Given the ambiguity you've cited, I strongly suggest that the charter >language /not/ gloss over any reasonable misunderstanding. Let's get >the language as tight and clear as we can. If we fail to account for the fact that there will be several delegate entities that can be legitimate signators for a given number, we will not capture the problem space. If the charter expresses the opposite of that, it will be a problem. Jon Peterson Neustar, Inc. >> - The deliverable for "the means of obtaining security-related >>parametric >> information." The literal means of obtaining keys/credentials, I think, >> are in the scope of the authorization validation method deliverable - >>for >> RFC4474, for example, this was the Identity-Info header and the URI >> schemes it described. You certainly can't do authorization validation >> without that means. I could read this deliverable as if it's suggesting >> that header or mechanism should be in a separate document. The original >> charter had "key management" as a separate deliverable, which is a >> slightly different scope. >> >> - The charter should be clear that we intend to obsolete RFC4474 and >> replace it with something, regardless of whether or not that happens to >>be >> one of our current input drafts. > >I see a separate sub-thread happening on this, so I'll wait to modify >draft charter text until that's resolved. > >FWIW, my own reading of RFC4474 causes me to think that dealing with it >for the current effort will primarily add confusion rather than benefit, >especially since it has a broader scope and it appears to have no >meaningful deployment this many years after IETF approval. > >d/ >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From york@isoc.org Thu Jun 27 17:43: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 23EBC21F9BBC for ; Thu, 27 Jun 2013 17:43:47 -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=[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 z5MDmp-X1bZB for ; Thu, 27 Jun 2013 17:43:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8250B21F9A50 for ; Thu, 27 Jun 2013 17:43:38 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB065.namprd06.prod.outlook.com (10.242.187.143) with Microsoft SMTP Server (TLS) id 15.0.702.21; Fri, 28 Jun 2013 00:43:36 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.130]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.15]) with mapi id 15.00.0702.005; Fri, 28 Jun 2013 00:43:36 +0000 From: Dan York To: Hadriel Kaplan , "Peterson, Jon" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc3HM9YtJF733FU2YC5ujHHk75ZlKHh8A///o+wA= Date: Fri, 28 Jun 2013 00:43:35 +0000 Message-ID: In-Reply-To: <1F10D3A5-D2C8-4088-A80E-4683822C5B1E@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: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(189002)(199002)(76786001)(53806001)(50986001)(63696002)(74876001)(54356001)(59766001)(47976001)(77982001)(69226001)(49866001)(46102001)(54316002)(76482001)(56776001)(51856001)(80022001)(65816001)(47736001)(4396001)(36756003)(74366001)(77096001)(76796001)(79102001)(74502001)(76176001)(56816003)(31966008)(74706001)(16406001)(74662001)(81342001)(81542001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB065; H:BLUPR06MB067.namprd06.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <0DC353EBD9E0DC49AB2C28C45FE99441@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 00:43:47 -0000 On 6/27/13 6:06 PM, "Hadriel Kaplan" wrote: >Up front I should be clear about one thing: I thought we had been told >that the real-world problem we need to solve and focus on and quickly fix >is bogus/spoofed caller-id. I'm not saying we might not also end up >solving other things simultaneously with the same mechanism, enough so >that we can really replace RFC4474 - I'm just saying we shouldn't be >constrained to having to do so by putting it in the charter right now. >It might turn out we can replace 4474, but we don't know that yet. +1 to this and also to Henning's list of potential outcomes. I think we need to focus on getting something out - and getting something *deployed* - that solves the phone number secure origin problem we've been talking about. I worry that adding in a requirement that we need to obsolete/replace RFC 4474 will create additional delays and steps in the process of getting a solution out and deployed. If, as we are repeatedly being told, "no one is using RFC 4474" because of its problems, than does anyone really care if RFC 4474 gets obsoleted or just hangs around as yet-another-RFC-that-is-ignored? A better approach may be to get a STIR solution out and deployed as rapidly as possible and then separately run a 4474bis process that potentially incorporates the STIR solution and makes other modifications - and obsoletes 4474. My 2 cents, Dan From michael.hammer@yaanatech.com Thu Jun 27 19:15: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 8C8D711E8150 for ; Thu, 27 Jun 2013 19:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 3K9bGBah8e6I for ; Thu, 27 Jun 2013 19:15: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 7C63211E815C for ; Thu, 27 Jun 2013 19:15: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; Thu, 27 Jun 2013 19:14:45 -0700 From: Michael Hammer To: "jon.peterson@neustar.biz" , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgABPfZ4AACnddIA== Date: Fri, 28 Jun 2013 02:15:44 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0E6E5@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012E_01CE736A.B885B0E0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 02:15:51 -0000 ------=_NextPart_000_012E_01CE736A.B885B0E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jon, Interesting. What I hope to do as a recipient is not to have to be divining tea leaves. What you suggest below seems to me to be a pre-processor step that should be wholly within the domain that wants to muck around with the From header. By the time the From reaches the "public" network (or egress or interop point) I would hope it is clear where and what is the number. I can't rely on the From if I can't read it. Mike -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Thursday, June 27, 2013 5:11 PM To: Michael Hammer; hadriel.kaplan@oracle.com Cc: stir@ietf.org; dcrocker@bbiw.net Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >Agree. But, I may be looking for something a little more stringent. > >First, you have to have a string that has a canonical form. >If it is not, then the string is likely something out of scope. Not sure what you mean. >Second, you have to have a place in a header that you can be guaranteed >to find that canonical form. No, actually, I think the idea is just the opposite, that the canonical form would not appear as a literal in the message. Both the auth service and the verification service must have an algorithm that will let them derive the (single identical) canonical form from what they find in the From, however scungy it may be. >We seem to be very squishy about that. I don't want to have to know >the secret hand-shake to understand that. Secret handshakes are to be avoided, yes. >(Standard versus clubs) A recipient should not have to have a >different flavor or handling for aaa.com or bbb.com, or ... >Note, what someone does intra-domain may not matter. At least at the >inter-domain boundary, be standard. > >Third, if the normal rules state that the context of a string is >defined by a domain and not by the standard, and, since you have >previously stated (I think) that the domain can do whatever it wants >with the user part, then I really can't know that any user part string >is an E.164 or something else. >So, if it is within the scope of a domain, all bets are off. It is just an assumption of this model that the canonicalization is possible. Clearly it is conceivable that a verification service will receive a From and be unable to canonicalize the contents of its user part into a valid telephone number - that would be an identity failure. If intermediary systems cause that to happen, their policies would have to change for identity to be possible. >The degree of flexibility you want to preserve is probably directly >proportional to the degree of non-interoperability you will get. The only thing this is trying to preserve is interoperability with existing systems that rely on the From. Jon Peterson Neustar, Inc. > >Mike > > >-----Original Message----- >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Thursday, June 27, 2013 11:17 AM >To: Hadriel Kaplan; Michael Hammer >Cc: stir@ietf.org; dcrocker@bbiw.net >Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > >>It does not matter if it started as 'sip:5551212@aaa.com;user=phone' >>and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >>terminator uses it as the E.164 phone number '12125551212' in his >>systems and caller-id displays, then what he really needs to know is >>that this call request came from someone with the authority to claim >>'12125551212' - he does *not* need to know it really came from >>'bbb.com', nor that it came from user '+1-212-555-1212', nor even that >>it >came from SIP. > >Perhaps what some folks are missing here is the clear statement that >both the auth service and the verification service need to canonicalize >the From number to E.164 (actually a bit of a variant, but glossing >over for >now) as a part of the signature generation/verification process. > >The idea is basically this: when the auth signature is placed over >sip:5551212@aaa.com, the auth service canonicalizes 5551212 to >"12125551212", and that is what is signed over in the digest-strig of >the Identity header. In RFC4474 terms, this canonicalized string would >take the place of the addr-spec of the AoR in Section 9. When the >verification service receives +1-212-555-1212@bbb.com, it too >canonicalizes that to >12125551212 for the purposes of regenerating the digest-string. Thus it >doesn't matter how From is munged. Nor do you need to store a copy of >the number anywhere in the message, which for the various reasons >previously discussed won't work. > >The requirement here that both the auth service and verification >service canonicalize numbers in the same fashion is absolute, and >perhaps non-trivial, but it's certainly way better than hop-by-hop protection. > >Jon Peterson >Neustar, Inc. > ------=_NextPart_000_012E_01CE736A.B885B0E0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODAyMTU0M1owIwYJKoZIhvcNAQkEMRYEFFWnQ2F14weuTgULzOEqjRNnRLTnMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAb5Eh+AWrmakV7E2SxGbrofAtM4plwE3MoQRZ6h/O HDVoaGHjxk7zFY+q5QmJl24Oiglm1ZxZ2Aue2EvAZ4mWNUuSgpMcE6QX0G++5fn45MFgdVATfHmZ ZS2SIuklApwSELPBbYbeRUqbZBbyUnvjGDqM50/AIWqKaCr2g+G+hNTi3rXfgoik3g4g7xdyoi/w CZNXSdlHjVIIRVjmtOTs5XHdA1DAPsV7g8SGMA6AdzRNbixpk5UUgaktQ66SxrePwZK2I6S4vZow z6Vib2mLU8Sr0AdKAWI13nfKUmx2gDgdbMvEPG1gR8RfQgCy/6gfxgXkoNTFSBkTGlPuzbExegAA AAAAAA== ------=_NextPart_000_012E_01CE736A.B885B0E0-- From michael.hammer@yaanatech.com Thu Jun 27 19:21: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 323A321F9433 for ; Thu, 27 Jun 2013 19:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 7kN96Sav3aFQ for ; Thu, 27 Jun 2013 19:21:02 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id EE91A21F93D4 for ; Thu, 27 Jun 2013 19:21: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; Thu, 27 Jun 2013 19:20:01 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgABQvIAAACo3ZMA== Date: Fri, 28 Jun 2013 02:21:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> In-Reply-To: <51CCD6C0.7050108@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0133_01CE736B.7529ED60" MIME-Version: 1.0 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 02:21:06 -0000 ------=_NextPart_000_0133_01CE736B.7529ED60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But then you get the situation where: A thinks X means Y, while B thinks X means Z. Verifying that it is truly X means different things to A and B. So, A signs X and sends to B to confirm that the number is Y. B verifies X and confirms that the number is Z. I don't think that is what we want. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, June 27, 2013 5:20 PM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Mike, On 6/27/13 5:53 PM, Michael Hammer wrote: > Agree. But, I may be looking for something a little more stringent. > > First, you have to have a string that has a canonical form. > If it is not, then the string is likely something out of scope. The presumption is that the strings are whatever is in From and To, and they they *are not* in canonical form. But it is assumed that the signer can look at whatever is in the From and To it sees, and generate a canonical form to sign. And that the verifier can look at whatever is in the From and To *it* sees, and generate the canonical form to verify. And that the get the same result! It is *not* assumed that the signer and the verifier are looking at the identical thing. Each may be looking at a non-canonical form that fits its local conventions, and that magic has resulted in the signer's form being transformed into the verifier's form. It seems to me to be a lousy way to run a railroad, but that is what the deployed systems apparently like to do. Thanks, Paul > Second, you have to have a place in a header that you can be > guaranteed to find that canonical form. > We seem to be very squishy about that. I don't want to have to know > the secret hand-shake to understand that. > (Standard versus clubs) A recipient should not have to have a > different flavor or handling for aaa.com or bbb.com, or ... > Note, what someone does intra-domain may not matter. At least at the > inter-domain boundary, be standard. > > Third, if the normal rules state that the context of a string is > defined by a domain and not by the standard, and, since you have > previously stated (I think) that the domain can do whatever it wants > with the user part, then I really can't know that any user part string > is an E.164 or something else. > So, if it is within the scope of a domain, all bets are off. > > The degree of flexibility you want to preserve is probably directly > proportional to the degree of non-interoperability you will get. > > Mike > > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, June 27, 2013 11:17 AM > To: Hadriel Kaplan; Michael Hammer > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > >> It does not matter if it started as 'sip:5551212@aaa.com;user=phone' >> and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >> terminator uses it as the E.164 phone number '12125551212' in his >> systems and caller-id displays, then what he really needs to know is >> that this call request came from someone with the authority to claim >> '12125551212' - he does *not* need to know it really came from >> 'bbb.com', nor that it came from user '+1-212-555-1212', nor even >> that it > came from SIP. > > Perhaps what some folks are missing here is the clear statement that > both the auth service and the verification service need to > canonicalize the From number to E.164 (actually a bit of a variant, > but glossing over for > now) as a part of the signature generation/verification process. > > The idea is basically this: when the auth signature is placed over > sip:5551212@aaa.com, the auth service canonicalizes 5551212 to > "12125551212", and that is what is signed over in the digest-strig of > the Identity header. In RFC4474 terms, this canonicalized string would > take the place of the addr-spec of the AoR in Section 9. When the > verification service receives +1-212-555-1212@bbb.com, it too > canonicalizes that to > 12125551212 for the purposes of regenerating the digest-string. Thus > it doesn't matter how From is munged. Nor do you need to store a copy > of the number anywhere in the message, which for the various reasons > previously discussed won't work. > > The requirement here that both the auth service and verification > service canonicalize numbers in the same fashion is absolute, and > perhaps non-trivial, but it's certainly way better than hop-by-hop protection. > > Jon Peterson > Neustar, Inc. > > > > _______________________________________________ > 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_0133_01CE736B.7529ED60 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODAyMjEwMFowIwYJKoZIhvcNAQkEMRYEFBDK2nxSVF3kaMgnoTQA1hsE4VDoMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALl8eyja3X1MCDrWJx1LcrJrdxhSGAhOdwYgfe/4T DFA/x7WAm/rjIOrFVcttg9ophsKX20Tf+kQMjEetvQ/Xchq/v6vbadZGoiTA7AhlydMlg/mdbnKP X6hzi2lXD679tIsYUD9wnRDCqFRn8hjXRMrbyrKSefAzwzTtK4mhQgBny8Qv/w2sa0IYI4AOwquy 6VhuE141aR1W49+Bgv7t6IDIhn2ekvmp2HMoGLhrMYVknoY5nYDxPgAdvEQ32NjHoRDMv4tgWi9j XBkTW5soaq6ogkOuAFeXCLDuU1WZcYGe8iWsfgRHvdIu60jnz5J5H7wbPdpPf42t4Np7KolVoQAA AAAAAA== ------=_NextPart_000_0133_01CE736B.7529ED60-- From pkyzivat@alum.mit.edu Thu Jun 27 21:50: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 D03B521F9A38 for ; Thu, 27 Jun 2013 21:50:13 -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 vvWb3PI64x-R for ; Thu, 27 Jun 2013 21:50:09 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2921F9AAE for ; Thu, 27 Jun 2013 21:50:07 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id tgpW1l0011ZXKqc5Dgq5JG; Fri, 28 Jun 2013 04:50:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id tgq41l00h3ZTu2S3hgq4s2; Fri, 28 Jun 2013 04:50:05 +0000 Message-ID: <51CD15FC.1080004@alum.mit.edu> Date: Fri, 28 Jun 2013 00:50:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Hammer References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@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=1372395005; bh=DvEbhEvrrQJlz/UUY7+u4Nz0A6yadq9i+VAuQ5SmvGQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gbk1h5QB1IIeoApRBHS8+C0eIx08FPeP6bCUlJ4zDzaHZqJd4RJojdqw5St4R77Wk DzV4lMLMviEz/cxcbDMJDnP+brCU5qJ7QYczcLZwG93TzP7UNgUSuCVzS0Oioy6DJL 19aK027a0mtwW/7CTxOUmDUlL61sT2gvxEZt2ABvevI3i22oAEb32nu6jyuHOHUJ9d w+vW0voCFRBP+SMAkTNMQdad6vU2ZXfG6msQUCxHF8iI/9HDyv+vdPCnRDlMnQNH2l tu4Zzw+kLlZzXQS+Mw2oE9IyVfWfl3Z4XO2r/Xy3Xw6sqQJe1LTy35764Dqdk2STa5 5ifG8t16M4y2Q== Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 04:50:14 -0000 On 6/27/13 10:21 PM, Michael Hammer wrote: > But then you get the situation where: > A thinks X means Y, while > B thinks X means Z. > Verifying that it is truly X means different things to A and B. > So, A signs X and sends to B to confirm that the number is Y. > B verifies X and confirms that the number is Z. I thought Jon did a good job of explaining this. In the above case, A thinks X means Y, so A generates a signature over Y. Then when B attempts to verify, it does so over Z, so the verification fails. > I don't think that is what we want. Its not what we want. And hopefully its not what A and B want either. So I guess they would be motivated to agree on the meaning of X. The real world implication of this is that A provides X as the callerid. To call A, in general you must call some dial string that yields the E.164 Y. When this reaches B, perhaps X is displayed as the callerid. But when used as a dial string in B's context, it calls the E.164 Z. Since a callback wouldn't reach A, its reasonable that the callerid doesn't verify. IMO this just highlights the need to move to a world where E.164 numbers are passed around. If desired, they can be *rendered* as convenient dial string that corresponds to that E.164, but that should be a local action. Or we could just give up on phone numbers because they are unfixable. Thanks, Paul > Mike > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Thursday, June 27, 2013 5:20 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > Mike, > > On 6/27/13 5:53 PM, Michael Hammer wrote: >> Agree. But, I may be looking for something a little more stringent. >> >> First, you have to have a string that has a canonical form. >> If it is not, then the string is likely something out of scope. > > The presumption is that the strings are whatever is in From and To, and they > they *are not* in canonical form. But it is assumed that the signer can look > at whatever is in the From and To it sees, and generate a canonical form to > sign. And that the verifier can look at whatever is in the From and To *it* > sees, and generate the canonical form to verify. > And that the get the same result! > > It is *not* assumed that the signer and the verifier are looking at the > identical thing. Each may be looking at a non-canonical form that fits its > local conventions, and that magic has resulted in the signer's form being > transformed into the verifier's form. > > It seems to me to be a lousy way to run a railroad, but that is what the > deployed systems apparently like to do. > > Thanks, > Paul > >> Second, you have to have a place in a header that you can be >> guaranteed to find that canonical form. >> We seem to be very squishy about that. I don't want to have to know >> the secret hand-shake to understand that. >> (Standard versus clubs) A recipient should not have to have a >> different flavor or handling for aaa.com or bbb.com, or ... >> Note, what someone does intra-domain may not matter. At least at the >> inter-domain boundary, be standard. >> >> Third, if the normal rules state that the context of a string is >> defined by a domain and not by the standard, and, since you have >> previously stated (I think) that the domain can do whatever it wants >> with the user part, then I really can't know that any user part string >> is an E.164 or something else. >> So, if it is within the scope of a domain, all bets are off. >> >> The degree of flexibility you want to preserve is probably directly >> proportional to the degree of non-interoperability you will get. >> >> Mike >> >> >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: Thursday, June 27, 2013 11:17 AM >> To: Hadriel Kaplan; Michael Hammer >> Cc: stir@ietf.org; dcrocker@bbiw.net >> Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >> >> >>> It does not matter if it started as 'sip:5551212@aaa.com;user=phone' >>> and got received as 'sip:+1-212-555-1212@bbb.com'; because if the >>> terminator uses it as the E.164 phone number '12125551212' in his >>> systems and caller-id displays, then what he really needs to know is >>> that this call request came from someone with the authority to claim >>> '12125551212' - he does *not* need to know it really came from >>> 'bbb.com', nor that it came from user '+1-212-555-1212', nor even >>> that it >> came from SIP. >> >> Perhaps what some folks are missing here is the clear statement that >> both the auth service and the verification service need to >> canonicalize the From number to E.164 (actually a bit of a variant, >> but glossing over for >> now) as a part of the signature generation/verification process. >> >> The idea is basically this: when the auth signature is placed over >> sip:5551212@aaa.com, the auth service canonicalizes 5551212 to >> "12125551212", and that is what is signed over in the digest-strig of >> the Identity header. In RFC4474 terms, this canonicalized string would >> take the place of the addr-spec of the AoR in Section 9. When the >> verification service receives +1-212-555-1212@bbb.com, it too >> canonicalizes that to >> 12125551212 for the purposes of regenerating the digest-string. Thus >> it doesn't matter how From is munged. Nor do you need to store a copy >> of the number anywhere in the message, which for the various reasons >> previously discussed won't work. >> >> The requirement here that both the auth service and verification >> service canonicalize numbers in the same fashion is absolute, and >> perhaps non-trivial, but it's certainly way better than hop-by-hop > protection. >> >> Jon Peterson >> Neustar, Inc. >> >> >> >> _______________________________________________ >> 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 Jun 27 21:59: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 39DC321F9E22 for ; Thu, 27 Jun 2013 21:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, 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 uLMLQhBDvFzA for ; Thu, 27 Jun 2013 21:59:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AB96B21F9E32 for ; Thu, 27 Jun 2013 21:59:14 -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 r5S4qqrP024982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 04:52:53 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 r5S4xBS4014116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 04:59:11 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 r5S4xACP012865; Fri, 28 Jun 2013 04:59:10 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 21:59: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: <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@EX2K10MB1.corp.yaanatech.com> Date: Fri, 28 Jun 2013 00:59:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2ABCC42C-CF00-4705-A5A1-0EB4D4AC7453@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "stir@ietf.org" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 04:59:21 -0000 I think you guys either keep missing the point, or you choose to ignore = it. The point is we have proof the concept can work, because things = work today. It simply can't be the case that domain A thinks a literal "X" means Y, = and domain B thinks literal "X" means Z, and that a message domain A = sent had "X" written on it and when B got it it still says "X". Because = if that were true, things wouldn't work right now - forget signing = anything, or STIR, or whatever. Domain A and B couldn't be = communicating today if that were the case. Calls would be going to the = wrong people all day. So clearly, by the time domain B gets the message = from domain A, the message must now say something that means Y to domain = B - it could be a literal "Y", or it could be "W". It doesn't actually = matter what the literal string is, so long as A and B both can figure = out it means Y. And we're going to have domain A sign as if it said Y = all along, not the literal "X"; and we're going to have domain B verify = for Y as well, not the literal "W" or whatever. We just won't make them = change whatever literal character it is they use on-the-wire already. I know it sucks - no one's saying it's the ideal world. It will = probably take some configuration, on the signing system or verifying = system or both. But that's better than changing configuration, code, or = behavior of every other system in all the domains at the same instant. And it's not as bad as it seems, either. It's not like people are = changing "+12125551212" into "djbDVbovur". :) -hadriel On Jun 27, 2013, at 10:21 PM, Michael Hammer = wrote: > But then you get the situation where: > A thinks X means Y, while > B thinks X means Z. > Verifying that it is truly X means different things to A and B. > So, A signs X and sends to B to confirm that the number is Y. > B verifies X and confirms that the number is Z. >=20 > I don't think that is what we want. >=20 > Mike From dhc@dcrocker.net Thu Jun 27 22:10: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 F12B721F9EAC for ; Thu, 27 Jun 2013 22:10:43 -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 7bK873Htjsh5 for ; Thu, 27 Jun 2013 22:10:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 032CD21F9E9E for ; Thu, 27 Jun 2013 22:10:35 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-143-183.san.res.rr.com [76.93.143.183]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5S5AWRU032616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 22:10:35 -0700 Message-ID: <51CD1AC1.5010106@dcrocker.net> Date: Thu, 27 Jun 2013 22:10:25 -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: "Peterson, Jon" 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, 27 Jun 2013 22:10:35 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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: Fri, 28 Jun 2013 05:10:44 -0000 On 6/27/2013 5:40 PM, Peterson, Jon wrote: >> No doubt, some signers will be telcos or other operators, and this might >> seem confusing, but they are doing it /on behalf of/ the end user. Even >> if real end users happen not to know their calls are being protected >> with a signature on their behalf, it is on their behalf. It's not "by" >> the operator. They are a delegate of the user. > > I think many people on this list would view telcos signing as the everyday > case, and end-user signators as the exception. From an assignment > perspective, carriers are certainly not (in contemporary North America > anyway) delegates of the user; users are delegates of the carrier. > Moreover there are plenty of other actors, like resellers, enterprises, > etc who are also delegates and potentially signers. The problem again with > the "the entity formally assigned use" language is that it treats the > concept of "assignee" as if numbers have a single authority, but the > reason "assignee" is a better term here than "owner" is because it doesn't > have the connotation that there's some single authority. Numbering doesn't > work that way. End users are not working "on behalf of" the provider. The term "delegate" would mean they were... So, no, the end user is not a delegate of the telco. It's important not to confuse the mechanics of some actions with the roles being performed. We need to distinguish among several different roles and several different actions and a couple of different legitimization models. Values are administered, possibly through a hierarchy. Ultimately, they are assigned for 'use'. Look into a reverse white pages and you won't find reference to the telco or Neustar. You'll find the user who answers the phone. Administrators are not 'users'. Yeah, they mess with the value, but they are performing support functions. Operators also perform some functions that touch the value. Back when telephone numbers were tied to switch topology, of course, the relationship was tighter. But again, they are not 'users'. They are providers. The difference is fundamental. We need to avoid confusing support functions -- whether administration or operations -- from assignment to the end-user. The history with telephone numbers has conflated a number of different roles into the same set of actors. Number portability highlights that they really are different roles. They further make clear that the assignment of the number is detached from the telco that assigns it to the end user. Yes, the number can be taken back from the end user, but not at the whim of the telco. And it's generally not permitted to say 'owner' when a continued licensing fee is required to retain rights. Lastly is the role of vouching for validity. The end user can vouch for their own use, because have that authority. But it's plausible that others might do the vouching, either because the end user delegated that right to them or because the services that check for validity lend credence to some other agents. This moves from a simple, objective assignment-based model for validation to one that looks more like third-party reputation. So a telco doing signing is fine, either because they are doing it with the user's implicit/explicit permission, or because the assessment service chooses to treat the telco as a trusted agent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Thu Jun 27 23:11: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 C343521F8ECE for ; Thu, 27 Jun 2013 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 ol2bd-U7EXcN for ; Thu, 27 Jun 2013 23:11:25 -0700 (PDT) Received: from userp1050.oracle.com (userp1050.oracle.com [156.151.31.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D121F9BFF for ; Thu, 27 Jun 2013 23:10:24 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by userp1050.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5S6AL4V007898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Jun 2013 06:10:22 GMT 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 r5S62bAE018125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Jun 2013 06:02:38 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 r5S68ut6024510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Jun 2013 06:08:56 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 r5S68uuT024507 for ; Fri, 28 Jun 2013 06:08:56 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 23:08:56 -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: <51CCD6C0.7050108@alum.mit.edu> Date: Fri, 28 Jun 2013 02:08:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> To: "stir@ietf.org" X-Mailer: Apple Mail (2.1508) X-Source-IP: userp1040.oracle.com [156.151.31.81] Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 06:11:46 -0000 Maybe an analogy would help... Let's say you're a member of the New Hampshire division of the American = Automobile Association (AAA) in the USA. And let's say AAA provides = their members with a web-form to fill out if they want to complain about = a car design defect, and that AAA sends the complaint on to the Better = Business Bureau (BBB), who then sends the complaint on to the car = manufacturer. So you go on the New Hampshire AAA website and fill out a form to = complain about your car, a Dodge Durango SUV - Dodge being a division of = Chrysler Car Company (CCC). The AAA web-form has a field asking you = what your phone-number is, so that you can be contacted for more = information if need be. And let's say since this website is for New = Hampshire members, that the web-form accepts a phone-number such as the = literal string "555-1212". There's no +1 needed because it's a US-based = customer web-form, and no "603" area-code because it knows you're from = New Hampshire. So AAA has some back-end systems that crunch this web-form input, and = those systems have no idea what format the Dodge Durango Division (DDD) = of Chrysler Car Company (CCC) expects to get it as. But they do know = how the BBB expects it, and the BBB expects it in the format = "603-555-1212", so the AAA back-end systems convert it to that and send = it to the BBB. The BBB likewise doesn't know Dodge's format, but they = know Chrysler and their format, so BBB's systems convert it to CCC's = which is "+16035551212". Chrysler then routes this complaint to Dodge = Durango Division, who happens to expect it as "+1.603.555.1212". So we have: 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> = +1.603.555.1212@DDD.com None of these domains along the way are "confused" about what your = number really is, yet they all have a different syntactic representation = for it on-the-wire. So along comes the IETF, and we're worried that customer complaint forms = are getting received by car companies with spoofed customer contact = phone-numbers. What should we do? Should we say: "sorry, everyone's systems are broken = - please go fix them all to use a single syntax so we can sign and = verify it on both ends". That wouldn't happen, and isn't necessary. Instead, we're saying: "the forms are what they are to each domain and = we can't change that, but the New Hampshire AAA signing system has to = sign the E.164 equivalent to what its form says, and the Dodge Durango = Division verification system has to verify the E.164 equivalent to what = its form says." =20 It sounds silly, but it will work - both AAA and DDD do know what the = E.164 really is, regardless of what was put in the complaint form, and = despite the fact they have no idea what format/syntax the other one = uses. And the proof of that is that their complaint form mechanism = works today already; it's just getting spoofed with fake numbers. -hadriel p.s. This was a fictional example - I have no idea if AAA provides = complaint web-forms or how they get to Dodge. :) On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > Mike, >=20 > On 6/27/13 5:53 PM, Michael Hammer wrote: >> Agree. But, I may be looking for something a little more stringent. >>=20 >> First, you have to have a string that has a canonical form. >> If it is not, then the string is likely something out of scope. >=20 > The presumption is that the strings are whatever is in =46rom and To, = and they they *are not* in canonical form. But it is assumed that the = signer can look at whatever is in the =46rom and To it sees, and = generate a canonical form to sign. And that the verifier can look at = whatever is in the =46rom and To *it* sees, and generate the canonical = form to verify. And that the get the same result! >=20 > It is *not* assumed that the signer and the verifier are looking at = the identical thing. Each may be looking at a non-canonical form that = fits its local conventions, and that magic has resulted in the signer's = form being transformed into the verifier's form. >=20 > It seems to me to be a lousy way to run a railroad, but that is what = the deployed systems apparently like to do. >=20 > Thanks, > Paul From wilhelm@wimmreuter.de Thu Jun 27 23:22: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 2D2CF21F9DFA for ; Thu, 27 Jun 2013 23:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQZKlXSDl7sr for ; Thu, 27 Jun 2013 23:22:44 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A48B521F9DF5 for ; Thu, 27 Jun 2013 23:22:43 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MCT7F-1V0wOB1uoj-009nOu; Fri, 28 Jun 2013 08:22:42 +0200 Received: by wwnet.ww (Postfix, from userid 783) id D3790100E19; Fri, 28 Jun 2013 08:22:41 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 33A83100D70; Fri, 28 Jun 2013 08:22:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: Date: Fri, 28 Jun 2013 08:22:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:H1ZTlMrxa1yZnmGdNLWu3YIJPo2T2L6irVSn0fQ/JMM Ym6vGvZbqfNqnoCdmA9PkdbXMmCn3YOt8gJCzpliMzrtbTmXUa FLOIGXZww7pZfePkE/ubdzLGtdleJAPLHY3v78gm8q9yklkQL+ CLNpfiMv+6uX/aHwf8vdK+5TW6jH/Kz814zz/X+wYDfPe3oDFJ 0335rpdQfv0LyX4E2XnLnitDyDzNHZHNUjxbdtGvHBwFoRYige 6Lmyxx57x+5ShIGQ90jNW+haG4wGu5+18cQ2TLjA8FFDrwvi5N mretY3v7IN5Rlt+sUS71iQONHEykuk1a/yNM/FkjyWUOVFehj6 kDLYWQ1uEq6K4FjZX6qvqTbQnEEMyseqISD9HKgPp Cc: "stir@ietf.org" , Hadriel Kaplan , "dcrocker@bbiw.net" , "Peterson, Jon" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 06:22:54 -0000 Yes,=20 as Henning states:=20 Starting out with "limited signing" for the number is the basic thing we = shall do for a start. The Pro's + This gives a strong authentication of the Caller-ID + Every one in the chain can validate + We protect "the user" instead of "the transport & service" ... IP is not based "Trust by Wire" anymore ;-) + We can re-use the authentication for other cases including encryption + Operators can force users to assert the final Caller-ID format without modifying it later - MITM fiddling is still possible - We need authoritative validation services (CA)s=20 for initial enrollment of phone numbers Further evolution can start when=20 1.) Operators learn that they are signing at most "on behalf"=20 of the user or endpoint as Dave mentions,=20 2.) Endpoints learn to sign and validate themselves,=20 3.) SIP can turn in to a real e2e service where operators will become the connection agent as we see it with DNS Willi On 27.06.2013, at 23:27, Henning Schulzrinne wrote: > Several outcomes are possible, and it seems unnecessary to pick one at = this time: >=20 > - Leave 4474 alone and create something suited to STIR E.164 needs = that can co-exist with 4474, but is otherwise independent (new header = field, new logic, etc.). >=20 > - Update 4474 for the number case (and more limited signing). >=20 > - Replace 4474, and thus address both E.164 (tel/SIP) and non-E.164 = SIP URLs. >=20 > This will partially depend on the "how to look up certs/public keys" = debate outcome, so I see little advantage in picking one of the options = now. While I don't think we'd intentionally break 4474 implementations, = should they exist, without good cause, backward compatibility isn't the = primary concern here, unlike in other "bis" efforts where everybody = wants to be assured that the new effort at least won't break old boxes. >=20 > ________________________________________ > From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of = Hadriel Kaplan [hadriel.kaplan@oracle.com] > Sent: Thursday, June 27, 2013 3:14 PM > To: Peterson, Jon > Cc: stir@ietf.org; dcrocker@bbiw.net > Subject: [stir] Replacing rfc4474 (was: Revised charter text for STIR) >=20 > On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" = wrote: >=20 >> - The charter should be clear that we intend to obsolete RFC4474 and >> replace it with something, regardless of whether or not that happens = to be >> one of our current input drafts. >=20 > It's likely that the resulting outcome of this WG ends up being a much = narrower assertion of stuff being protected/authenticated - in = particular, it might only end up protecting the caller-id for a given = request, and nothing more. ISTM that rfc4474 tried to 'protect' things = that went beyond simply the caller-id of a request. So if we *only* = protect the caller-id, will you be comfortable with replacing RFC4474? >=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 >=20 From wilhelm@wimmreuter.de Thu Jun 27 23:45: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 0AA8921F9E16 for ; Thu, 27 Jun 2013 23:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdhxKfBukkIT for ; Thu, 27 Jun 2013 23:44:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 943B521F9C39 for ; Thu, 27 Jun 2013 23:44:25 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MYJFd-1UnniL2I0v-00Ver4; Fri, 28 Jun 2013 08:44:24 +0200 Received: by wwnet.ww (Postfix, from userid 783) id B8ABF100F4B; Fri, 28 Jun 2013 08:44:23 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id BF71A100D64; Fri, 28 Jun 2013 08:44:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <51CD1AC1.5010106@dcrocker.net> Date: Fri, 28 Jun 2013 08:44:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC429B5-5130-46F0-8C10-B474CE7BAADD@wimmreuter.de> References: <51CD1AC1.5010106@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:hcPQBqF3MWkuekEUw+ul8ReWk7FPboDl5XrZjc6nxA4 enNMTF1E8QApSPaVvMeap1rtxFWckhQgxDEYAip8wE/S7oN5/h NJ5MUJgVV3OS/K3731ITZyloOmjD+HkT5I59z2eZeC0tM4RDB/ 9Q3svwKY8S5S0tiHZGOU1nT2rHRnnlnqaMFEBq9nv+tBh7oDyH ZZG94rFXHI+8fUsCZnaTBvkT1eHx4LiaRYU4qbz7VrR41um+nJ 1K86r3V2GgmALz6nkg38abjapqxQOwUUjE0DSyQ1v7PoNH5CHx Omx0wScsxFCrQVdqtM87e3pvBU7azbNU1YFe2OyUrNzjjH/D2q Nu9Y6PhaagqdRFBPPcg8qQgIYLX8uSSyQrDunUYYt Cc: "stir@ietf.org" , "Peterson, Jon" Subject: Re: [stir] Revised charter text for 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, 28 Jun 2013 06:45:04 -0000 Dave, I fully agree with the "on behalf of" and "delegation" view=20 I would go a step further state that end users=20 "optionally delegate the signing power to the operator" and thereby allow the operator to sign on behalf of the end-user. ... of course this is the default case today. In the long term this will change. Shall we add something like this as a basic assumption to the charter? This will make the STIR work much simpler and at least it will be a = clear statement how to deal with this old paradigms in the scope of = STIR. ... we are on the Internet and not on closed "Trust by Wire" networks = anymore. Willi On 28.06.2013, at 07:10, Dave Crocker wrote: > On 6/27/2013 5:40 PM, Peterson, Jon wrote: >>> No doubt, some signers will be telcos or other operators, and this = might >>> seem confusing, but they are doing it /on behalf of/ the end user. = Even >>> if real end users happen not to know their calls are being protected >>> with a signature on their behalf, it is on their behalf. It's not = "by" >>> the operator. They are a delegate of the user. >>=20 >> I think many people on this list would view telcos signing as the = everyday >> case, and end-user signators as the exception. =46rom an assignment >> perspective, carriers are certainly not (in contemporary North = America >> anyway) delegates of the user; users are delegates of the carrier. >> Moreover there are plenty of other actors, like resellers, = enterprises, >> etc who are also delegates and potentially signers. The problem again = with >> the "the entity formally assigned use" language is that it treats the >> concept of "assignee" as if numbers have a single authority, but the >> reason "assignee" is a better term here than "owner" is because it = doesn't >> have the connotation that there's some single authority. Numbering = doesn't >> work that way. >=20 >=20 >=20 > End users are not working "on behalf of" the provider. The term = "delegate" would mean they were... So, no, the end user is not a = delegate of the telco. >=20 > It's important not to confuse the mechanics of some actions with the = roles being performed. We need to distinguish among several different = roles and several different actions and a couple of different = legitimization models. >=20 >=20 > Values are administered, possibly through a hierarchy. Ultimately, = they are assigned for 'use'. Look into a reverse white pages and you = won't find reference to the telco or Neustar. You'll find the user who = answers the phone. >=20 > Administrators are not 'users'. Yeah, they mess with the value, but = they are performing support functions. >=20 > Operators also perform some functions that touch the value. Back when = telephone numbers were tied to switch topology, of course, the = relationship was tighter. But again, they are not 'users'. They are = providers. The difference is fundamental. >=20 > We need to avoid confusing support functions -- whether administration = or operations -- from assignment to the end-user. >=20 > The history with telephone numbers has conflated a number of different = roles into the same set of actors. Number portability highlights that = they really are different roles. They further make clear that the = assignment of the number is detached from the telco that assigns it to = the end user. >=20 > Yes, the number can be taken back from the end user, but not at the = whim of the telco. And it's generally not permitted to say 'owner' when = a continued licensing fee is required to retain rights. >=20 >=20 > Lastly is the role of vouching for validity. The end user can vouch = for their own use, because have that authority. But it's plausible that = others might do the vouching, either because the end user delegated that = right to them or because the services that check for validity lend = credence to some other agents. This moves from a simple, objective = assignment-based model for validation to one that looks more like = third-party reputation. >=20 > So a telco doing signing is fine, either because they are doing it = with the user's implicit/explicit permission, or because the assessment = service chooses to treat the telco as a trusted agent. >=20 > d/ >=20 >=20 >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From wilhelm@wimmreuter.de Thu Jun 27 23:56: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 4B46B21F9D88 for ; Thu, 27 Jun 2013 23:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x7siTFjBGW2 for ; Thu, 27 Jun 2013 23:56:43 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74C21F9BF0 for ; Thu, 27 Jun 2013 23:56:34 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Mh8o1-1Uf2MS2ou9-00MREy; Fri, 28 Jun 2013 08:56:33 +0200 Received: by wwnet.ww (Postfix, from userid 783) id C4922100F54; Fri, 28 Jun 2013 08:56:32 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 719461003F5; Fri, 28 Jun 2013 08:56:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Wilhelm Wimmreuter In-Reply-To: <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> Date: Fri, 28 Jun 2013 08:56:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39F78C74-63C8-4996-BF6F-E3CD98B7237E@wimmreuter.de> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:hHOb3e5Vu+V0WAuulD2aEbgdaXqX5qK87uXVjEUejDP mPUkqdCVHKksy+Ru8Rcqs1az/q+SE5ObkQhe4im5X/RyAi/5xk 97+0e91HpIzJATyhstYldEqVNaEVp7/7QDby8iDxY8M6n/LWDS Y+xldUTEroYpPuZqkQQwdwCXA5w/9OQyyDfGv3eGPeLWyr4WBg Ad/vb6DMhsBwBGnrpFew6Eu/hBxQ803uclhzP2+5nzsMbvKhcz hWiGWGYn91erfHuiLVgjIyjy2C3xVE1PmiBPLk3ByIFgQYq+GS eRigK566n1Oy+5iswIyFFdcyzCG95YpdU4HiHuGPx5+fVtBM4c Du4epSOQ7ZeWxaSJFXursBo+pbu2FFVmVODncOPKJ Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 06:56:58 -0000 Yes, this is a sample of legitimate Caller-ID spoofing ;-) However, there are solutions for it. We can allow multiple signees for each phone number and thus there is a = solution for re-signing as long as it is guaranteed that all signees are = enrolled and authenticated by the CA. This will be a classic PKI = delegation and will be perfectly valid. As such, PKI can support our beloved hop-by-hop model as well. Of course, this will require that all "re-signees" are enrolled as a = delegated authoritative signee for this particular number as well. So = your example can be served well by PKI delegation models. Willi On 28.06.2013, at 08:08, Hadriel Kaplan wrote: >=20 > Maybe an analogy would help... >=20 > Let's say you're a member of the New Hampshire division of the = American Automobile Association (AAA) in the USA. And let's say AAA = provides their members with a web-form to fill out if they want to = complain about a car design defect, and that AAA sends the complaint on = to the Better Business Bureau (BBB), who then sends the complaint on to = the car manufacturer. >=20 > So you go on the New Hampshire AAA website and fill out a form to = complain about your car, a Dodge Durango SUV - Dodge being a division of = Chrysler Car Company (CCC). The AAA web-form has a field asking you = what your phone-number is, so that you can be contacted for more = information if need be. And let's say since this website is for New = Hampshire members, that the web-form accepts a phone-number such as the = literal string "555-1212". There's no +1 needed because it's a US-based = customer web-form, and no "603" area-code because it knows you're from = New Hampshire. >=20 > So AAA has some back-end systems that crunch this web-form input, and = those systems have no idea what format the Dodge Durango Division (DDD) = of Chrysler Car Company (CCC) expects to get it as. But they do know = how the BBB expects it, and the BBB expects it in the format = "603-555-1212", so the AAA back-end systems convert it to that and send = it to the BBB. The BBB likewise doesn't know Dodge's format, but they = know Chrysler and their format, so BBB's systems convert it to CCC's = which is "+16035551212". Chrysler then routes this complaint to Dodge = Durango Division, who happens to expect it as "+1.603.555.1212". >=20 > So we have: > 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> = +1.603.555.1212@DDD.com >=20 > None of these domains along the way are "confused" about what your = number really is, yet they all have a different syntactic representation = for it on-the-wire. >=20 > So along comes the IETF, and we're worried that customer complaint = forms are getting received by car companies with spoofed customer = contact phone-numbers. >=20 > What should we do? Should we say: "sorry, everyone's systems are = broken - please go fix them all to use a single syntax so we can sign = and verify it on both ends". That wouldn't happen, and isn't necessary. >=20 > Instead, we're saying: "the forms are what they are to each domain and = we can't change that, but the New Hampshire AAA signing system has to = sign the E.164 equivalent to what its form says, and the Dodge Durango = Division verification system has to verify the E.164 equivalent to what = its form says." =20 >=20 > It sounds silly, but it will work - both AAA and DDD do know what the = E.164 really is, regardless of what was put in the complaint form, and = despite the fact they have no idea what format/syntax the other one = uses. And the proof of that is that their complaint form mechanism = works today already; it's just getting spoofed with fake numbers. >=20 > -hadriel > p.s. This was a fictional example - I have no idea if AAA provides = complaint web-forms or how they get to Dodge. > :) >=20 >=20 > On Jun 27, 2013, at 8:20 PM, Paul Kyzivat = wrote: >=20 >> Mike, >>=20 >> On 6/27/13 5:53 PM, Michael Hammer wrote: >>> Agree. But, I may be looking for something a little more stringent. >>>=20 >>> First, you have to have a string that has a canonical form. >>> If it is not, then the string is likely something out of scope. >>=20 >> The presumption is that the strings are whatever is in =46rom and To, = and they they *are not* in canonical form. But it is assumed that the = signer can look at whatever is in the =46rom and To it sees, and = generate a canonical form to sign. And that the verifier can look at = whatever is in the =46rom and To *it* sees, and generate the canonical = form to verify. And that the get the same result! >>=20 >> It is *not* assumed that the signer and the verifier are looking at = the identical thing. Each may be looking at a non-canonical form that = fits its local conventions, and that magic has resulted in the signer's = form being transformed into the verifier's form. >>=20 >> It seems to me to be a lousy way to run a railroad, but that is what = the deployed systems apparently like to do. >>=20 >> Thanks, >> Paul >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From michael.hammer@yaanatech.com Fri Jun 28 01:42: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 9E28D21F9C8A for ; Fri, 28 Jun 2013 01:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J69M3xX+MkVr for ; Fri, 28 Jun 2013 01:42:06 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 46CA721F9CAB for ; Fri, 28 Jun 2013 01:42:06 -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, 28 Jun 2013 01:42:03 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgABQvIAAADC3FgAAJqlXA Date: Fri, 28 Jun 2013 08:42:02 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> In-Reply-To: <73D968BC-49DF-4F0F-8896-E1304A28C06F@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.47] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01CE73A0.ADA47180" MIME-Version: 1.0 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 08:42:15 -0000 ------=_NextPart_000_0008_01CE73A0.ADA47180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hadriel, Re: So AAA has some back-end systems that crunch this web-form input, and those systems have no idea what format the Dodge Durango Division (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do know how the BBB expects it... STOP right there. That is an assumption that will often not hold. And is precisely my problem. You assume that any given sender knows how to format for every given recipient. The issue of dots, dashes, or none is a sideshow. What if AAA decides to send as: From: 555-1212@AAA.com And if BBB looks at that and because BBB is in another area code (703), it thinks that to extract, interpret, and expand it becomes +1-703-555-1212 versus +1-603-555-1212 then you get errors. Now compound that with different countries. You will gets lots of failures. The phone system routes on other headers, so what is in the From header doesn't matter, so using that as an argument of "well the system knows how to route" doesn't mean anything. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, June 27, 2013 11:09 PM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Maybe an analogy would help... Let's say you're a member of the New Hampshire division of the American Automobile Association (AAA) in the USA. And let's say AAA provides their members with a web-form to fill out if they want to complain about a car design defect, and that AAA sends the complaint on to the Better Business Bureau (BBB), who then sends the complaint on to the car manufacturer. So you go on the New Hampshire AAA website and fill out a form to complain about your car, a Dodge Durango SUV - Dodge being a division of Chrysler Car Company (CCC). The AAA web-form has a field asking you what your phone-number is, so that you can be contacted for more information if need be. And let's say since this website is for New Hampshire members, that the web-form accepts a phone-number such as the literal string "555-1212". There's no +1 needed because it's a US-based customer web-form, and no "603" area-code because it knows you're from New Hampshire. So AAA has some back-end systems that crunch this web-form input, and those systems have no idea what format the Dodge Durango Division (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do know how the BBB expects it, and the BBB expects it in the format "603-555-1212", so the AAA back-end systems convert it to that and send it to the BBB. The BBB likewise doesn't know Dodge's format, but they know Chrysler and their format, so BBB's systems convert it to CCC's which is "+16035551212". Chrysler then routes this complaint to Dodge Durango Division, who happens to expect it as "+1.603.555.1212". So we have: 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> +1.603.555.1212@DDD.com None of these domains along the way are "confused" about what your number really is, yet they all have a different syntactic representation for it on-the-wire. So along comes the IETF, and we're worried that customer complaint forms are getting received by car companies with spoofed customer contact phone-numbers. What should we do? Should we say: "sorry, everyone's systems are broken - please go fix them all to use a single syntax so we can sign and verify it on both ends". That wouldn't happen, and isn't necessary. Instead, we're saying: "the forms are what they are to each domain and we can't change that, but the New Hampshire AAA signing system has to sign the E.164 equivalent to what its form says, and the Dodge Durango Division verification system has to verify the E.164 equivalent to what its form says." It sounds silly, but it will work - both AAA and DDD do know what the E.164 really is, regardless of what was put in the complaint form, and despite the fact they have no idea what format/syntax the other one uses. And the proof of that is that their complaint form mechanism works today already; it's just getting spoofed with fake numbers. -hadriel p.s. This was a fictional example - I have no idea if AAA provides complaint web-forms or how they get to Dodge. :) On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > Mike, > > On 6/27/13 5:53 PM, Michael Hammer wrote: >> Agree. But, I may be looking for something a little more stringent. >> >> First, you have to have a string that has a canonical form. >> If it is not, then the string is likely something out of scope. > > The presumption is that the strings are whatever is in From and To, and they they *are not* in canonical form. But it is assumed that the signer can look at whatever is in the From and To it sees, and generate a canonical form to sign. And that the verifier can look at whatever is in the From and To *it* sees, and generate the canonical form to verify. And that the get the same result! > > It is *not* assumed that the signer and the verifier are looking at the identical thing. Each may be looking at a non-canonical form that fits its local conventions, and that magic has resulted in the signer's form being transformed into the verifier's form. > > It seems to me to be a lousy way to run a railroad, but that is what the deployed systems apparently like to do. > > Thanks, > Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0008_01CE73A0.ADA47180 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODA4NDE1OFowIwYJKoZIhvcNAQkEMRYEFHkwlU93p6B0fk+v7ZPjXQKTMxkwMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAH3Pu+pF9CrjpwVeFvKsr77lMXK7TXEPeCuWs1S9T aKnoPY3ZpqGlS0GOM/32q2P9hzzS5R3Q42aH1dGIHf5oKBxoBmddqSSG4SUEclSB+SemPkmOsxqk syqSyMfRtfus+dpR+LB58MHNWqyMeWXaflOkzHK15aoighDhwqeLGkTMX4GZMTicvqx/1SZwaI2V 8DgCgKwTsp9Mqm5DBZSr/pNlKyfwxuW7RULFDv5/qBbp2GmXDYPY9TEaNfM6AHSY9Sf19wSN1KoP /esG29GzxuSGFvFECNdUCh4W20dNvbbIoKScnPTnRQ3x3/yGHslORbGO1ojh5puTM9nuq3xrpgAA AAAAAA== ------=_NextPart_000_0008_01CE73A0.ADA47180-- From pp3129@att.com Fri Jun 28 05:48: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 B631321F9A90 for ; Fri, 28 Jun 2013 05:48: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 SVoMKWJhircc for ; Fri, 28 Jun 2013 05:48:47 -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 0062821F9A8C for ; Fri, 28 Jun 2013 05:44:20 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4258dc15.0.5966403.00-055.16594089.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 12:44:21 +0000 (UTC) X-MXL-Hash: 51cd8525325a6b94-2c7dbaa536e41230d11f2638a57e7b296f6a1a99 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 r5SCiKqp001128; Fri, 28 Jun 2013 08:44:20 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5SCiA8a000954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 08:44:15 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 12:43:53 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 08:44:02 -0400 From: "PFAUTZ, PENN L" To: Hadriel Kaplan , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgAA3lzQAADC3FgAAFZ9KQ Date: Fri, 28 Jun 2013 12:44:01 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60497499A@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> In-Reply-To: <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.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.20.146] X-AnalysisOut: [v=2.0 cv=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=OoZRMSaFez8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=yHFaGRWuWKcA:10 a=48vgC7mUAAAA:8 a=E-KWtq0EAAAA:8] X-AnalysisOut: [ a=ixZpCcfQAAAA:8 a=jEIl9BPeAAAA:8 a=80HKUY7iAAAA:8 a=7jBU] X-AnalysisOut: [O1D5hPR8Xr_lg3EA:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:10 a=H] X-AnalysisOut: [kkh2TJMae4A:10 a=lZB815dzVvQA:10 a=1FsIqRueSKIA:10 a=9a5i8] X-AnalysisOut: [eoXIgkA:10 a=S1rS4hP1KdcA:10 a=zUhrCSjc5OkA:10 a=Mh15xOQgz] X-AnalysisOut: [o-yK2rY:21 a=Kze_1Y32cq0f9wLH:21] Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 12:48:59 -0000 +1 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 Had= riel Kaplan Sent: Friday, June 28, 2013 2:09 AM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Maybe an analogy would help... Let's say you're a member of the New Hampshire division of the American Aut= omobile Association (AAA) in the USA. And let's say AAA provides their mem= bers with a web-form to fill out if they want to complain about a car desig= n defect, and that AAA sends the complaint on to the Better Business Bureau= (BBB), who then sends the complaint on to the car manufacturer. So you go on the New Hampshire AAA website and fill out a form to complain = about your car, a Dodge Durango SUV - Dodge being a division of Chrysler Ca= r Company (CCC). The AAA web-form has a field asking you what your phone-n= umber is, so that you can be contacted for more information if need be. An= d let's say since this website is for New Hampshire members, that the web-f= orm accepts a phone-number such as the literal string "555-1212". There's = no +1 needed because it's a US-based customer web-form, and no "603" area-c= ode because it knows you're from New Hampshire. So AAA has some back-end systems that crunch this web-form input, and those= systems have no idea what format the Dodge Durango Division (DDD) of Chrys= ler Car Company (CCC) expects to get it as. But they do know how the BBB e= xpects it, and the BBB expects it in the format "603-555-1212", so the AAA = back-end systems convert it to that and send it to the BBB. The BBB likewi= se doesn't know Dodge's format, but they know Chrysler and their format, so= BBB's systems convert it to CCC's which is "+16035551212". Chrysler then = routes this complaint to Dodge Durango Division, who happens to expect it a= s "+1.603.555.1212". So we have: 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> +1.603.= 555.1212@DDD.com None of these domains along the way are "confused" about what your number r= eally is, yet they all have a different syntactic representation for it on-= the-wire. So along comes the IETF, and we're worried that customer complaint forms ar= e getting received by car companies with spoofed customer contact phone-num= bers. What should we do? Should we say: "sorry, everyone's systems are broken - = please go fix them all to use a single syntax so we can sign and verify it = on both ends". That wouldn't happen, and isn't necessary. Instead, we're saying: "the forms are what they are to each domain and we c= an't change that, but the New Hampshire AAA signing system has to sign the = E.164 equivalent to what its form says, and the Dodge Durango Division veri= fication system has to verify the E.164 equivalent to what its form says." It sounds silly, but it will work - both AAA and DDD do know what the E.164= really is, regardless of what was put in the complaint form, and despite t= he fact they have no idea what format/syntax the other one uses. And the p= roof of that is that their complaint form mechanism works today already; it= 's just getting spoofed with fake numbers. -hadriel p.s. This was a fictional example - I have no idea if AAA provides complain= t web-forms or how they get to Dodge. :) On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > Mike, > > On 6/27/13 5:53 PM, Michael Hammer wrote: >> Agree. But, I may be looking for something a little more stringent. >> >> First, you have to have a string that has a canonical form. >> If it is not, then the string is likely something out of scope. > > The presumption is that the strings are whatever is in From and To, and t= hey they *are not* in canonical form. But it is assumed that the signer can= look at whatever is in the From and To it sees, and generate a canonical f= orm to sign. And that the verifier can look at whatever is in the From and = To *it* sees, and generate the canonical form to verify. And that the get t= he same result! > > It is *not* assumed that the signer and the verifier are looking at the i= dentical thing. Each may be looking at a non-canonical form that fits its l= ocal conventions, and that magic has resulted in the signer's form being tr= ansformed into the verifier's form. > > It seems to me to be a lousy way to run a railroad, but that is what the = deployed systems apparently like to do. > > Thanks, > Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Fri Jun 28 06: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 0541E21F9F32 for ; Fri, 28 Jun 2013 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQOPi5AHLW2z for ; Fri, 28 Jun 2013 06:01:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3A21F994C for ; Fri, 28 Jun 2013 05:54:47 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-143-183.san.res.rr.com [76.93.143.183]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SCshx7007563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 05:54:46 -0700 Message-ID: <51CD878C.5070005@dcrocker.net> Date: Fri, 28 Jun 2013 05:54:36 -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: Hadriel Kaplan References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> In-Reply-To: <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 28 Jun 2013 05:54:47 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) 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: Fri, 28 Jun 2013 13:01:14 -0000 On 6/27/2013 11:08 PM, Hadriel Kaplan wrote: > Instead, we're saying: "the forms are what they are to each domain > and we can't change that, but the New Hampshire AAA signing system > has to sign the E.164 equivalent to what its form says, and the Dodge > Durango Division verification system has to verify the E.164 > equivalent to what its form says." Context-dependent forms, for global values, became antithetical to Internet standards at least 35 years ago. They are fragile enough to threaten interoperability. The issue isn't that one can specify a scenario that can work, but how easily one can instead fall into a scenario that doesn't; notably, take the form, without context descriptors, and give it to someone else, such as if Dodge moves and the form isn't converted to the new, local conventions. But alas, as you've made clear, the use of the From field is established practice. So we have to start with text along the lines of your "signers and verifiers convert the number to its E.164 equivalent, before performing the cryptographic functions." My guess is that the non-e.164 forms have limited variations. That is, I suspect we/you know what other forms the number can be in. I suggest performing the case analysis, listing each and specifying what is needed to covert it to E.164. Absent something like this, we've got an Internet standard that begins with reliance on whatever local heuristic folks feel like using. Heuristics are essential to some programing but, as I said, they are antithetical to global standards. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From philippe.fouquart@orange.com Fri Jun 28 06: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 7801C21F9F26 for ; Fri, 28 Jun 2013 06:12:55 -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, 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 Fk6NhFSCRPvp for ; Fri, 28 Jun 2013 06:12:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D6BBF21F9E77 for ; Fri, 28 Jun 2013 06:12:50 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 16A3A324C80; Fri, 28 Jun 2013 15:12:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E242635C05B; Fri, 28 Jun 2013 15:12:49 +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; Fri, 28 Jun 2013 15:12:49 +0200 From: To: Michael Hammer , "hadriel.kaplan@oracle.com" , "stir@ietf.org" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnZ3/hLluPGOEKb3ApjFKidb5k+fdWAgAAjSaCAAAwagIABMoTggABz3QCABLKbMIAAz44AgACHpfCAABKwAIAACiiAgAAVTgCAAAL9AIAAIBoAgADZkICAAF9KAIAAA26AgACLhoCAAAMNAIAACYQAgAAqmQCAAC/PAIAAvjyAgAAOJwCAABpsAIAAPHeAgAApGwCAAGFugIAAKsMAgABlxzA= Date: Fri, 28 Jun 2013 13:12:48 +0000 Message-ID: <21159_1372425170_51CD8BD1_21159_199_8_B5939C6860701C49AA39C5DA5189448B0B0B20@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.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.5.21.113319 Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 13:12:55 -0000 > What if AAA decides to send as: From: 555-1212@AAA.com >=20 > And if BBB looks at that and because BBB is in another area code (703), it > thinks that to extract, interpret, and expand it becomes +1-703-555-1212 > versus +1-603-555-1212 then you get errors. > Now compound that with different countries. You will gets lots of failur= es. I don't know if the following will help but the reason why this would fail = in theory but is indeed going to work in practice IMHO is that the number o= f those "implicit contexts" that signers and verifiers share is limited and= not combinatory (and more or less match the legacy Numbering Plan / Type o= f Number of other signaling oddly enough...): a) (no context) full international b) national c) local d) private (out of scope)=20 If for some reason, the signer sends a local format outside the area code o= r a national format cross border, verification is indeed going to fail beca= use the canonical form cannot be derived from the CgP, but as Hadriel said = the calling party number is meaningless to the callee anyway regardless of = what stir does. All other cases where the full context is not provided will= happen within the above categories not across.=20 The question for stir might be whether that may provide a backdoor to avoid= a "reject unsigned CLI" policy, but the problem is there anyway - and agai= n quite limited.=20 Now as I've already said, since what is conveyed and what is displayed are = too different things, I'm still convinced that providing the full format if= it's not too much work for the caller is always preferable, but not everyo= ne does that, such is life. [it seems this is along the lines of what Dave's just posted but I still ho= pe it helps :)]=20 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 Mic= hael Hammer Sent: Friday, June 28, 2013 10:42 AM To: hadriel.kaplan@oracle.com; stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Hadriel, Re: So AAA has some back-end systems that crunch this web-form input, and those systems have no idea what format the Dodge Durango Division (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do know how the BBB expects it... STOP right there. That is an assumption that will often not hold. And is precisely my problem. You assume that any given sender knows how to format for every given recipient. The issue of dots, dashes, or none is a sideshow. What if AAA decides to send as: From: 555-1212@AAA.com And if BBB looks at that and because BBB is in another area code (703), it thinks that to extract, interpret, and expand it becomes +1-703-555-1212 versus +1-603-555-1212 then you get errors. Now compound that with different countries. You will gets lots of failures. The phone system routes on other headers, so what is in the From header doesn't matter, so using that as an argument of "well the system knows how to route" doesn't mean anything. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, June 27, 2013 11:09 PM To: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) Maybe an analogy would help... Let's say you're a member of the New Hampshire division of the American Automobile Association (AAA) in the USA. And let's say AAA provides their members with a web-form to fill out if they want to complain about a car design defect, and that AAA sends the complaint on to the Better Business Bureau (BBB), who then sends the complaint on to the car manufacturer. So you go on the New Hampshire AAA website and fill out a form to complain about your car, a Dodge Durango SUV - Dodge being a division of Chrysler Car Company (CCC). The AAA web-form has a field asking you what your phone-number is, so that you can be contacted for more information if need be. And let's say since this website is for New Hampshire members, that the web-form accepts a phone-number such as the literal string "555-1212". There's no +1 needed because it's a US-based customer web-form, and no "603" area-code because it knows you're from New Hampshire. So AAA has some back-end systems that crunch this web-form input, and those systems have no idea what format the Dodge Durango Division (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do know how the BBB expects it, and the BBB expects it in the format "603-555-1212", so the AAA back-end systems convert it to that and send it to the BBB. The BBB likewise doesn't know Dodge's format, but they know Chrysler and their format, so BBB's systems convert it to CCC's which is "+16035551212". Chrysler then routes this complaint to Dodge Durango Division, who happens to expect it as "+1.603.555.1212". So we have: 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> +1.603.555.1212@DDD.com None of these domains along the way are "confused" about what your number really is, yet they all have a different syntactic representation for it on-the-wire. So along comes the IETF, and we're worried that customer complaint forms are getting received by car companies with spoofed customer contact phone-numbers. What should we do? Should we say: "sorry, everyone's systems are broken - please go fix them all to use a single syntax so we can sign and verify it on both ends". That wouldn't happen, and isn't necessary. Instead, we're saying: "the forms are what they are to each domain and we can't change that, but the New Hampshire AAA signing system has to sign the E.164 equivalent to what its form says, and the Dodge Durango Division verification system has to verify the E.164 equivalent to what its form says."=20=20 It sounds silly, but it will work - both AAA and DDD do know what the E.164 really is, regardless of what was put in the complaint form, and despite the fact they have no idea what format/syntax the other one uses. And the proof of that is that their complaint form mechanism works today already; it's just getting spoofed with fake numbers. -hadriel p.s. This was a fictional example - I have no idea if AAA provides complaint web-forms or how they get to Dodge. :) On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > Mike, >=20 > On 6/27/13 5:53 PM, Michael Hammer wrote: >> Agree. But, I may be looking for something a little more stringent. >>=20 >> First, you have to have a string that has a canonical form. >> If it is not, then the string is likely something out of scope. >=20 > The presumption is that the strings are whatever is in From and To, and they they *are not* in canonical form. But it is assumed that the signer can look at whatever is in the From and To it sees, and generate a canonical form to sign. And that the verifier can look at whatever is in the From and To *it* sees, and generate the canonical form to verify. And that the get the same result! >=20 > It is *not* assumed that the signer and the verifier are looking at the identical thing. Each may be looking at a non-canonical form that fits its local conventions, and that magic has resulted in the signer's form being transformed into the verifier's form. >=20 > It seems to me to be a lousy way to run a railroad, but that is what the deployed systems apparently like to do. >=20 > Thanks, > Paul _______________________________________________ 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 wilhelm@wimmreuter.de Fri Jun 28 07:00: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 C859A21F9AA9 for ; Fri, 28 Jun 2013 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moYbwJ1g8W9X for ; Fri, 28 Jun 2013 07:00:05 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B921F9A77 for ; Fri, 28 Jun 2013 06:59:44 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lr6Rz-1UNt653tml-00eWAH; Fri, 28 Jun 2013 15:59:43 +0200 Received: by wwnet.ww (Postfix, from userid 783) id 06C1910124D; Fri, 28 Jun 2013 15:59:41 +0200 (CEST) Received: from [192.168.178.24] (unknown [192.168.178.24]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 7F4E910123F; Fri, 28 Jun 2013 15:59:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Wilhelm Wimmreuter In-Reply-To: Date: Fri, 28 Jun 2013 15:59:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E502F34-57B8-439B-A439-8235369CA87D@wimmreuter.de> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:7MMpHOCOOvfdyi3c22yYz6qjEuT7pT8eDzvPRait1lb xYjEnsJv+SuTJXh5yHbL8MZHjXDnQlk3/C1jkCZbNCGNscIDw0 VlImoJCY/IItdJ6IMv3FQ+OaH5ea72Dlx8BjJoPmrINQNPYXLB QaFaPf/84WQ/c2UN9gxMCzJbYVPESmEbxogrDlK8eQcmGC8lHE Y4c19oWFIYRw45Zgeakz6u1a/ga5VL4CZ/pASpNCaLfSbv20Th eNAijJP+sTNS5fJ2em6T9hIjFIVSb8K6cLHHhCOtNAEt/s3f8y 7n6En+FuexTbLDDGIsJDOLHXZeS93QkhOtuZLFSjp3CyfeURn4 6BbzBCui0tVl9rFcri2x8NrJFVtyYSFIi38PV4un0 Cc: "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] current draft 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, 28 Jun 2013 14:00:09 -0000 Sorry, overlooked this replay. Guess it basically does not matter how many certs we have. There must be just be at least one authoritative cert be attached to = each number. This can be a cert of an end-user or the cert of the operator that is = attached to multiple numbers in case the operator / PBX or service = provider signs "on behalf of" users. Such a model also would allow re-signing of "legitimate spoofers" such = as call-centers and that like. It perfectly supports a delegation model which by default can be setup = in a way to make the telco the primary signee and that allows the end = user become a signee later on. ... This of course will allow some fiddling on the access part prior we = reach the signee in that case the telco. Therefore we shall try to make = the end-user the only signee for the long run. Willi On 12.06.2013, at 19:49, Peterson, Jon wrote: >=20 > If I understand you correctly, I agree this is a model we should = explore: > one where an authority over a number (like a carrier) could sign a > credential controlled by an end user, who then uses that delegated > authority to assert identity in a SIP request. While the end user = cert, as > you say, conceivably might not have the phone number in its cname or > subjectAltName or what have you, relying parties could verify that the > credential that signed this end user cert does indeed have that = authority > in scope. >=20 > I don't think anyone here expects a model where there would literally = be a > new certificate for every telephone number, but in some use cases, = having > a certificate for an individual telephone number might be appropriate. = I > don't think we need to make this an either/or choice, though, both = models > can coexist peaceably. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/12/13 2:52 AM, "Wilhelm Wimmreuter" = wrote: >=20 >> Question on identifier usage: >>=20 >> Could one think about a model where the identifier "phone number" is >> asserted in the digest of the service request and signed by any >> authorized identity of the originating authority or user? >>=20 >>=20 >> Identifier: Authoritative Signee: >> +1 xxx yyy zzzz Signs private key of assigned >> or delegated certificate >> This cert does not necessary need the >> phone number as a Cname or alt-cname >>=20 >> This would solve a number of issues discussed in various threats I = think. >> It also would allow free binding to existing certificates and could = avoid >> generating yet another cert for each phone number. >> We shall avoid ending up in the same lifetime management issues as we >> know from passwords today. >>=20 >> Willi >> On 12.06.2013, at 03:46, Stephen Farrell wrote: >>=20 >>>=20 >>> So based on many recent mails, I'd suggest adding "and threat model" >>> to the problem statement deliverable and s/certificate/key = management/g >>> might be better so as not to preclude a non-certificate based >>> solution. >>>=20 >>> And one near-nit: I think the term "identity" generates quite a bit >>> of confusion and its generally better to talk about identifiers and >>> not identities. In other cases that's more of a deal but since we're >>> only dealing with phone numbers here its almost a nit. >>>=20 >>> Cheers, >>> S. >>>=20 >>> On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>>>=20 >>>> Below is the current draft of the charter, based on our prior >>>> discussions. >>>>=20 >>>> Jon Peterson >>>> Neustar, Inc. >>>>=20 >>>> ---- >>>>=20 >>>> Name: Secure Telephone Identity Revisited (stir) >>>> Area: RAI >>>>=20 >>>> Chairs: TBD >>>> Area Advisor: TBD (Barnes) >>>>=20 >>>> Mailing list: (current source-auth) >>>> To Subscribe: -- >>>>=20 >>>> Over the last decade, a growing set of problems have resulted from = the >>>> lack of security mechanisms for attesting the origins of real-time >>>> communications. Many of these problems are familiar from our = experience >>>> with email: bulk unsolicited commercial communications remain a >>>> challenge for the traditional telephone network largely because the >>>> source of calls can be hidden. Others are potentially more serious: >>>> voicemail hacking, impersonating banks and similar attacks are = becoming >>>> commonplace. The technologies that obscure the caller=B9s identity = are >>>> frequently gateways between the telephone network and the Internet. >>>>=20 >>>> SIP is one of the main VoIP technologies employed by these = gateways. A >>>> number of previous efforts have attacked the problem of securing = the >>>> origins of SIP communications, including RFC3325, RFC4474 and the = VIPR >>>> WG. To date, however, true cryptographic authentication of the = source >>>> of SIP calls has not seen any appreciable deployment. While several >>>> factors contributed to this lack of success, two seem like the = largest >>>> culprits: 1) the lack of any real means of asserting authority over >>>> telephone numbers on the Internet; and 2) a misalignment of the >>>> integrity mechanisms proposed by RFC4474 with the highly = interworked, >>>> mediated and policy-driven deployment environment that has emerged = for >>>> SIP. The VIPR alternative, while promising, faced apparently >>>> unavoidable privacy problems and other significant deployment = hurdles. >>>>=20 >>>> Given the pressing difficulties caused by the lack of a useful >>>> identity solution, the problem of securing the origins of SIP >>>> communication must be revisited. Because SIP deployments are so = closely >>>> tied to the telephone network, we moreover must investigate = solutions >>>> that can work when one side of a call is in the PSTN =AD or = potentially >>>> even both. This will require a two-pronged approach: one prong = relying >>>> on information carried in SIP signaling; the other prong relying on >>>> forming out-of-band connections between IP endpoints that are >>>> participating in a call. >>>>=20 >>>> The changes to the RFC4474 approach to SIP signaling must include a >>>> new capability for Identity assertions to cover telephone numbers, >>>> rather than domain names. To conform with realistic deployments, we >>>> must also study ways to rebalance the requirements for the scope of >>>> RFC4474=B9s integrity protection to emphasize preventing = third-party >>>> impersonation over preventing men-in-the-middle from capturing = media. >>>>=20 >>>> Finally, the solution must encompass an out-of-band means for >>>> endpoints to establish identity when there is no direct SIP = signaling >>>> path between them available, due to interworking or similar = factors. >>>> This working group will investigate a means for Internet endpoints = to >>>> discover one another in real time to verify that a telephone call >>>> between them is in progress based on minimal evidence or = configuration. >>>> This architecture will, to the degree that is possible, reuse the >>>> credentials defined for telephone numbers for the in-band signaling >>>> solution, and define a discovery mechanism that provides better = than >>>> hop-by-hop security. >>>>=20 >>>> The working group will coordinate with the security area on >>>> certificate management. >>>>=20 >>>> The working group will coordinate with RAI area groups studying the >>>> problem of signaling through existing deployments, including = INSIPID. >>>>=20 >>>> Identity is closely linked to privacy, and frequently one comes at = the >>>> cost of the other. This working group is not chartered to mandate = the >>>> presence of identity in SIP requests, and to the extent feasible it >>>> will find privacy-friendly solutions that leak minimal information >>>> about calls to third parties. >>>>=20 >>>> The working group will deliver the following: >>>>=20 >>>> - A problem statement detailing the deployment environment and >>>> difficulties motivate work on secure origins >>>>=20 >>>> - A revision to SIP=B9s identity features to provide several fixes: >>>> Changes to support certification for telephone numbers >>>> Changes to the signature >>>>=20 >>>> - A document describing the certificate profile required to support >>>> telephone numbers in certificates >>>>=20 >>>> - A fallback mechanism to allow out-of-band identity establishment >>>> during call setup >>>>=20 >>>> Milestones >>>>=20 >>>> Sep 2013 Submit problem statement for Info >>>> Nov 2013 Submit RFC4474bis for PS >>>> Jan 2013 Submit TN cert profile for Info >>>> Mar 2014 Submit fallback for PS >>>>=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 >>>=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 >=20 From hadriel.kaplan@oracle.com Fri Jun 28 08:08: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 9A93421F9C0E for ; Fri, 28 Jun 2013 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 mocWRLgloS8q for ; Fri, 28 Jun 2013 08:08:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36821F9C07 for ; Fri, 28 Jun 2013 08:08:02 -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 r5SF1fnO023629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 15:01:42 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5SF7xHO012300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 15:07:59 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5SF7wgf016906; Fri, 28 Jun 2013 15:07:58 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 08:07: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: <39F78C74-63C8-4996-BF6F-E3CD98B7237E@wimmreuter.de> Date: Fri, 28 Jun 2013 11:07:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A8EBA70-002F-4E48-96E1-13B199BA59B8@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <39F78C74-63C8-4996-BF6F-E3CD98B7237E@wimmreuter.de> To: Wilhelm Wimmreuter X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:08:08 -0000 On Jun 28, 2013, at 2:56 AM, Wilhelm Wimmreuter = wrote: > Yes, this is a sample of legitimate Caller-ID spoofing ;-) >=20 > However, there are solutions for it. > We can allow multiple signees for each phone number and thus there is = a solution for re-signing as long as it is guaranteed that all signees = are enrolled and authenticated by the CA. This will be a classic PKI = delegation and will be perfectly valid. >=20 > As such, PKI can support our beloved hop-by-hop model as well. > Of course, this will require that all "re-signees" are enrolled as a = delegated authoritative signee for this particular number as well. So = your example can be served well by PKI delegation models. You're joking Willi, right? I know you have a dry sense of humor, so I often can't tell when you're = joking or not. (sarcasm and dry humor doesn't always convey itself as such in email) -hadriel From ekr@rtfm.com Fri Jun 28 08:10: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 85FFF21F9AD7 for ; Fri, 28 Jun 2013 08:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 FL3D1WzZf4nF for ; Fri, 28 Jun 2013 08:10:21 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1621F8443 for ; Fri, 28 Jun 2013 08:10:20 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so640389qab.4 for ; Fri, 28 Jun 2013 08:10:20 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=KeOqeRWhZa4ez/b2XkaUfscl1/FtVTtchQ+Vat/bGOo=; b=dj2hgk9cNSXyNuIvbQSfoPj8UzvZ07TExWfumo4HnLsBEMvoiAqsj3I4bqVL6YHhfx AehU2qbq+DxSu8x3DdhcUcY60uLQdP0M87kjhizExw9ntveMZIE5gMTZ58IEvgiz4ffw Y/yrowADnw6bE5U3dgM8PmHu1Yox6BsIfXKpmgRZ/RZQNRsuD1Q2j//qrDuxwo2ATJ3l gLQaEbq8MrZSYsS6+z7zkgRt2vU7V9IN1ZdYaNsCIc+IjD21ZMb8Zzp+dJpW0G4x7kp8 M+drFZsgDwtZy9OlID0ZPoww4nr358XpaaI4zJQHGMJt6acIpQd7buSu7TxoQM9oRYDY B0Bw== X-Received: by 10.49.14.101 with SMTP id o5mr17640289qec.55.1372432220325; Fri, 28 Jun 2013 08:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 08:09:39 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <009001ce7282$7d68acd0$783a0670$@shockey.us> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> From: Eric Rescorla Date: Fri, 28 Jun 2013 08:09:39 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=047d7b676b3cf8a82c04e038462f X-Gm-Message-State: ALoCoQm5QU8A8RD1oCcPu8j6xPNkBCHHhzWqdt8GVt2Y/JBwIJbz+1qQboPlK8SauJSxIatjQQzn Cc: "Wendt, Chris" , Hadriel Kaplan , stir@ietf.org, Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:10:25 -0000 --047d7b676b3cf8a82c04e038462f Content-Type: text/plain; charset=ISO-8859-1 [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey wrote: > +1 as well ... take it out of the charter. > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Wendt, Chris > Sent: Tuesday, June 25, 2013 1:20 PM > To: > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band > > +1 > > On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: > > >> If that's truly the case - that we plan to do an in-band first, and when > that's done then an out-of-band one - then I propose we remove the > out-of-band from the charter. We can always re-charter and add new > deliverables when we're ready for an out-of-band mechanism; we re-charter > all the time in RAI groups. We might even decide by then that an > out-of-band mechanism should work very differently, or that defining one > isn't necessary, or that we don't have the right participants in the IETF > to > do so successfully. > >> > >> For now, by removing it from the charter, we can focus on one solution > and not have to debate about this aspect during the BOF nor WG meetings. I > am very worried that we won't have a successful BOF - where I measure > "success" as reaching consensus to create a Working Group. Lengthy > microphone debates kill BOFs, in my experience. (and I recognize you and > Russ and others have seen far more BOFs than I have, so maybe I've just > been > to the wrong ones ;) > > > > > > +1. > > > > Narrow, clear focus. > > > > Good. > > > > 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --047d7b676b3cf8a82c04e038462f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Semi-randomly picking a message to reply to...]

<= /div>
First, let me say that I'm not at all wedded to anythin= g in the proposal
that bears my name and that I presented a= t the original STIR meeting.
That proposal was designed to match a specific set of needs and<= /div>
if those needs aren't needed, then so much the better.<= /div>

With that said, my impression going in= to that meeting and from the
discussion so far was that in fact for the foreseeable future we= are
going to have environments where:

=
(1) We want to have secure caller-id
(2) We basically can't put anything meaningful in the messages that
go from caller to callee (I hasten to add that I don't know = anywhere
near enough about SS7 to know if that's true, = but that was my
impression).

If that's true, then it seems like we really should be consi= dering some
non-inband solution from the get-go.

So, for the people who favor not doing a non-inb= and solution, do you
think that one of the two claims above is untrue? Or do you just= don't
think it follows that we should be doing somethi= ng about it?

Thanks,
-Ekr



On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <richard@shockey.us> wrote:
+1 as well ... take it out of the charter.

-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of
Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbiw.net>
Cc: stir@ie= tf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first= , and when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter. =A0We can always re-charter and add new
deliverables when we're ready for an out-of-band mechanism; we re-chart= er
all the time in RAI groups. =A0We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in th= e IETF to
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. = =A0I
am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. =A0Len= gthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just= been
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

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

--047d7b676b3cf8a82c04e038462f-- From hadriel.kaplan@oracle.com Fri Jun 28 08: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 EA00221F9C1E for ; Fri, 28 Jun 2013 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 dulIxOqVkp2j for ; Fri, 28 Jun 2013 08:26:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 596A421F9C1B for ; Fri, 28 Jun 2013 08:26:23 -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 r5SFK2f8015108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 15:20:03 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 r5SFQKlU009845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 15:26:21 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5SFQKM5029236; Fri, 28 Jun 2013 15:26:20 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 08:26: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: <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> Date: Fri, 28 Jun 2013 11:26:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:26:29 -0000 But we have existence proof that cannot be the case: BBB could not = possibly be expanding it to +1-703-555-1212 today, because by the time = Dodge gets it they wouldn't be able to use it for the customer contact = number. I set the analogy up this way because it's similar to phone = calls: the =46rom is in fact being used by the terminating carrier = already right now; just like Dodge is already using the customer contact = number in the analogy. For example when it reaches your phone, your phone displays some = caller-id that has meaning to your phone/you, and it's not making the = mistake of showing +1-703-555-1212 for calls from +1-603-555-1212 today. = And the terminating carriers offer things like voicemail, CNAM, *69 = callback, and billing records - and all those things work right now, and = use the caller-id/From, and aren't getting confused about the area code. = And in fact even the transit carriers (ie, BBB) often use the =46rom = phone number today - they use it for least-cost-routing for example, and = billing. And the problem we're being told to go fix isn't that the terminating = carriers can't figure out the From's E.164 numbers - they can - their = problem is the caller-id's are being misrepresented on-purpose. =20 Or to bring it back to the car analogy: Dodge isn't telling us "we can't = figure out what the human put in AAA's original web-forms" - they're = telling us people are *lying* when they fill out the web-forms. -hadriel On Jun 28, 2013, at 4:42 AM, Michael Hammer = wrote: > Hadriel, >=20 > Re: So AAA has some back-end systems that crunch this web-form input, = and > those systems have no idea what format the Dodge Durango Division = (DDD) of > Chrysler Car Company (CCC) expects to get it as. But they do know how = the > BBB expects it... STOP right there. >=20 > That is an assumption that will often not hold. And is precisely my > problem. You assume that any given sender knows how to format for = every > given recipient. > The issue of dots, dashes, or none is a sideshow. >=20 > What if AAA decides to send as: From: 555-1212@AAA.com >=20 > And if BBB looks at that and because BBB is in another area code = (703), it > thinks that to extract, interpret, and expand it becomes = +1-703-555-1212 > versus +1-603-555-1212 then you get errors. > Now compound that with different countries. You will gets lots of = failures. >=20 > The phone system routes on other headers, so what is in the =46rom = header > doesn't matter, so using that as an argument of "well the system = knows how > to route" doesn't mean anything. >=20 > Mike >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Hadriel Kaplan > Sent: Thursday, June 27, 2013 11:09 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) >=20 >=20 > Maybe an analogy would help... >=20 > Let's say you're a member of the New Hampshire division of the = American > Automobile Association (AAA) in the USA. And let's say AAA provides = their > members with a web-form to fill out if they want to complain about a = car > design defect, and that AAA sends the complaint on to the Better = Business > Bureau (BBB), who then sends the complaint on to the car manufacturer. >=20 > So you go on the New Hampshire AAA website and fill out a form to = complain > about your car, a Dodge Durango SUV - Dodge being a division of = Chrysler Car > Company (CCC). The AAA web-form has a field asking you what your > phone-number is, so that you can be contacted for more information if = need > be. And let's say since this website is for New Hampshire members, = that the > web-form accepts a phone-number such as the literal string "555-1212". > There's no +1 needed because it's a US-based customer web-form, and no = "603" > area-code because it knows you're from New Hampshire. >=20 > So AAA has some back-end systems that crunch this web-form input, and = those > systems have no idea what format the Dodge Durango Division (DDD) of > Chrysler Car Company (CCC) expects to get it as. But they do know how = the > BBB expects it, and the BBB expects it in the format "603-555-1212", = so the > AAA back-end systems convert it to that and send it to the BBB. The = BBB > likewise doesn't know Dodge's format, but they know Chrysler and their > format, so BBB's systems convert it to CCC's which is "+16035551212". > Chrysler then routes this complaint to Dodge Durango Division, who = happens > to expect it as "+1.603.555.1212". >=20 > So we have: > 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> > +1.603.555.1212@DDD.com >=20 > None of these domains along the way are "confused" about what your = number > really is, yet they all have a different syntactic representation for = it > on-the-wire. >=20 > So along comes the IETF, and we're worried that customer complaint = forms are > getting received by car companies with spoofed customer contact > phone-numbers. >=20 > What should we do? Should we say: "sorry, everyone's systems are = broken - > please go fix them all to use a single syntax so we can sign and = verify it > on both ends". That wouldn't happen, and isn't necessary. >=20 > Instead, we're saying: "the forms are what they are to each domain and = we > can't change that, but the New Hampshire AAA signing system has to = sign the > E.164 equivalent to what its form says, and the Dodge Durango Division > verification system has to verify the E.164 equivalent to what its = form > says." =20 >=20 > It sounds silly, but it will work - both AAA and DDD do know what the = E.164 > really is, regardless of what was put in the complaint form, and = despite the > fact they have no idea what format/syntax the other one uses. And the = proof > of that is that their complaint form mechanism works today already; = it's > just getting spoofed with fake numbers. >=20 > -hadriel > p.s. This was a fictional example - I have no idea if AAA provides = complaint > web-forms or how they get to Dodge. > :) >=20 >=20 > On Jun 27, 2013, at 8:20 PM, Paul Kyzivat = wrote: >=20 >> Mike, >>=20 >> On 6/27/13 5:53 PM, Michael Hammer wrote: >>> Agree. But, I may be looking for something a little more stringent. >>>=20 >>> First, you have to have a string that has a canonical form. >>> If it is not, then the string is likely something out of scope. >>=20 >> The presumption is that the strings are whatever is in =46rom and To, = and > they they *are not* in canonical form. But it is assumed that the = signer can > look at whatever is in the =46rom and To it sees, and generate a = canonical > form to sign. And that the verifier can look at whatever is in the = =46rom and > To *it* sees, and generate the canonical form to verify. And that the = get > the same result! >>=20 >> It is *not* assumed that the signer and the verifier are looking at = the > identical thing. Each may be looking at a non-canonical form that fits = its > local conventions, and that magic has resulted in the signer's form = being > transformed into the verifier's form. >>=20 >> It seems to me to be a lousy way to run a railroad, but that is what = the > deployed systems apparently like to do. >>=20 >> Thanks, >> Paul >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From pp3129@att.com Fri Jun 28 08:38: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 6E2E721F8449 for ; Fri, 28 Jun 2013 08:38: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.001, 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 cfAlsHQXicf5 for ; Fri, 28 Jun 2013 08:38:09 -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 9297521F9BD3 for ; Fri, 28 Jun 2013 08:38:09 -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 1edadc15.2aab0d461940.5699958.00-513.15899779.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 15:38:09 +0000 (UTC) X-MXL-Hash: 51cdade14397f813-8fb2bc60334be354fcc557ab49542f3582301670 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 6ddadc15.0.5699872.00-422.15899512.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 15:38:07 +0000 (UTC) X-MXL-Hash: 51cdaddf7a43cfe2-8bb332d7c632771adef10fc6d88b0b408adbdd78 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 r5SFbvOj009424; Fri, 28 Jun 2013 11:37:58 -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 r5SFbhQE009223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 11:37:49 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 15:37:29 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 11:37:38 -0400 From: "PFAUTZ, PENN L" To: Eric Rescorla , Richard Shockey Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHOdBGqIKsKivPKkUOvgDXrso+WtZlLQKYg Date: Fri, 28 Jun 2013 15:37:37 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> 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_38726EDA2109264987B45E29E758C4D604974B18MISOUT7MSGUSR9N_" 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=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=bQRfyHg_r] X-AnalysisOut: [70A:10 a=48vgC7mUAAAA:8 a=k7Ga1wGzAAAA:8 a=b8OvNEjoAAAA:8 ] X-AnalysisOut: [a=_7UpRWHlKYJ5GUI2LUQA:9 a=CjuIK1q_8ugA:10 a=iE9YWIBck50A:] X-AnalysisOut: [10 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a] X-AnalysisOut: [=fcAx7uNQz4EA:10 a=E1Snkw02GREA:10 a=EclV_t1HoL-NFDlC:21 a] X-AnalysisOut: [=ZZN4CVXaywX4Tp_v:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=g] X-AnalysisOut: [KO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4A] X-AnalysisOut: [uCg-hUA:10 a=tXsnliwV7b4A:10 a=aCbJ8GLgdoKxwiXJ:21 a=HwqGb] X-AnalysisOut: [NROxbCiH-Rw:21 a=l2jT5vtAW4z9du_Q:21] Cc: "Wendt, Chris" , Hadriel Kaplan , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:38:15 -0000 --_000_38726EDA2109264987B45E29E758C4D604974B18MISOUT7MSGUSR9N_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric: Here's the problem I see: The out of band solution assumes that there is so= mething at the terminating end that is able to make use of the out of band = mechanism. This is not going to be generally true until the circuit switche= d network is mostly retired; customers hanging off a circuit switch aren't = going to be protected. Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don't see it happenin= g without major refits to the legacy network. So, I'd prefer to concentrate= on getting things right in the new world, even if that world isn't coming = as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eri= c Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen;= Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henni= ng Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_38726EDA2109264987B45E29E758C4D604974B18MISOUT7MSGUSR9N_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric:

Here’s the problem = I see: The out of band solution assumes that there is something at the term= inating end that is able to make use of the out of band mechanism. This is not going to be generally true until the circuit switched network = is mostly retired; customers hanging off a circuit switch aren’t goin= g to be protected.

Once we have end to end S= IP we can do something in-band.

People might like to have= a rapid solution but I just don’t see it happening without major ref= its to the legacy network. So, I’d prefer to concentrate on getting things right in the new world, even if that world isn’t coming as so= on as any of us would like.

 <= /p>

 <= /p>

 <= /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 Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian= Rosen; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

 

[Semi-randomly picking a message to reply to...]

 

First, let me say that I'm not at all wedded to anyt= hing in the proposal

that bears my name and that I presented at the origi= nal STIR meeting.

That proposal was designed to match a specific set o= f needs and

if those needs aren't needed, then so much the bette= r.

 

With that said, my impression going into that meetin= g and from the

discussion so far was that in fact for the foreseeab= le future we are

going to have environments where:

 

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful in th= e messages that

go from caller to callee (I hasten to add that I don= 't know anywhere

near enough about SS7 to know if that's true, but th= at was my

impression).

 

If that's true, then it seems like we really should = be considering some

non-inband solution from the get-go.

 

So, for the people who favor not doing a non-inband = solution, do you

think that one of the two claims above is untrue? Or= do you just don't

think it follows that we should be doing something a= bout it?

 

Thanks,

-Ekr

 

 

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <= ;richard@shockey.us= > wrote:

+1 as well ... take it out of the charter.<= /o:p>


-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbiw.net>=

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first, an= d when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter.  We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups.  We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. &n= bsp;I
am very worried that we won't have a successful BOF - where I measure
"success" as reaching consensus to create a Working Group.  = Lengthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

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

 

--_000_38726EDA2109264987B45E29E758C4D604974B18MISOUT7MSGUSR9N_-- From hadriel.kaplan@oracle.com Fri Jun 28 08:42: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 7939621F9C32 for ; Fri, 28 Jun 2013 08:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 pfzdw8uJvjxC for ; Fri, 28 Jun 2013 08:42:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1A21F9C2C for ; Fri, 28 Jun 2013 08:42:32 -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 r5SFfpud012276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 15:41:52 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 r5SFfoeI017463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 15:41:50 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5SFfnA3021761; Fri, 28 Jun 2013 15:41:50 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 08:41: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: Fri, 28 Jun 2013 11:41:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Wendt, Chris" , Richard Shockey , stir@ietf.org, Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:42:39 -0000 On Jun 28, 2013, at 11:09 AM, Eric Rescorla wrote: > First, let me say that I'm not at all wedded to anything in the = proposal > that bears my name and that I presented at the original STIR meeting. > That proposal was designed to match a specific set of needs and > if those needs aren't needed, then so much the better. >=20 > With that said, my impression going into that meeting and from the > discussion so far was that in fact for the foreseeable future we are > going to have environments where: >=20 > (1) We want to have secure caller-id > (2) We basically can't put anything meaningful in the messages that > go from caller to callee (I hasten to add that I don't know anywhere > near enough about SS7 to know if that's true, but that was my > impression). >=20 > If that's true, then it seems like we really should be considering = some > non-inband solution from the get-go. >=20 > So, for the people who favor not doing a non-inband solution, do you > think that one of the two claims above is untrue? Or do you just don't > think it follows that we should be doing something about it? We had a long email debate about it, and it's not as simple as that. = Even if one only considers those two claims in isolation, it's not as = simple as "yes" or "no" to *either* of those claims. I would give you = the readers-digest version, but undoubtedly it would be a subjective = view of it, and would just open up the debate all over again. I think, though, that we reached consensus not to have it in the charter = for this BOF and WG formation; that way we don't bog down the BOF = debating it on microphones and running out of time. We can always = recharter after there's a WG, if there's WG consensus to do so. And if = there isn't WG consensus to do so later, then that tells you this = particular WG shouldn't be doing it. -hadriel From fluffy@cisco.com Fri Jun 28 08:45: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 8F34A21F9ABB for ; Fri, 28 Jun 2013 08:45:30 -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 2pQ5bhaUhUnd for ; Fri, 28 Jun 2013 08:45:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0521F9AAE for ; Fri, 28 Jun 2013 08:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1126; q=dns/txt; s=iport; t=1372434325; x=1373643925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rqc7EI3qhuslS9LzZghNVGKriQ4W7fubYIW6zGj/ZvQ=; b=JAt0yIWDo59EuPyPJV1VddAkTDwmEs6GVQh7O/+xOX2mV1Vmi0hdAqHh pDdw0IDMsNyWmCKeioGO+EdyhulOxmwH5c8rRyPsgazgt+jeTrrqFKzSw Ou0ituW21a4Shxopr4SElJ/4gKnHOxsYOPn18VDo1cI1USugvDF6GYHco o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFABSvzVGtJV2d/2dsb2JhbABbgwkySb8GgQoWdIIjAQEBAwEBAQE3NAsQAgEIGAoUECcLJQIEDgUIiAEGDLtuBI8jAjEHgwRjA6kKgxGCKA X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228675343" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jun 2013 15:45:25 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5SFjPQk021354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 15:45:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 10:45:24 -0500 From: "Cullen Jennings (fluffy)" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWltYnZvv95kaD94jU8Kryd5lLmgGA Date: Fri, 28 Jun 2013 15:45:24 +0000 Message-ID: References: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> In-Reply-To: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.211] Content-Type: text/plain; charset="us-ascii" Content-ID: <97372C902C70B043B7CCA1350B7E6501@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 15:45:30 -0000 Just want to be clear we are trying to protect the caller-id for the call. = (i'd like to bold the "for the call" part of previous sentence).=20 On Jun 27, 2013, at 3:14 PM, Hadriel Kaplan wro= te: >=20 > On Jun 27, 2013, at 1:48 PM, "Peterson, Jon" w= rote: >=20 >> - The charter should be clear that we intend to obsolete RFC4474 and >> replace it with something, regardless of whether or not that happens to = be >> one of our current input drafts. >=20 > It's likely that the resulting outcome of this WG ends up being a much na= rrower assertion of stuff being protected/authenticated - in particular, it= might only end up protecting the caller-id for a given request, and nothin= g more. ISTM that rfc4474 tried to 'protect' things that went beyond simpl= y the caller-id of a request. So if we *only* protect the caller-id, will = you be comfortable with replacing RFC4474? >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From fluffy@cisco.com Fri Jun 28 08:45: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 EF4A121F9AA9 for ; Fri, 28 Jun 2013 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 CJGmcSBJSYgm for ; Fri, 28 Jun 2013 08:45:49 -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 DC4FA21F9AAB for ; Fri, 28 Jun 2013 08:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1372434349; x=1373643949; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kuX3JM3ADrW5EyYP5VLp0xYmkOH86+EAunhmS1/i72c=; b=VW8HIfiuyJ4v83wHx/zGuK+f3n3ct7XO2c07f0WZvzGMmriRrFZUV6zx t/LTH1J135Gn5vfsAHvKNbKHuzL1eyH8Sx8bA85IVBj6NOYGebTByTRzH 0idILBDnrSb/7SXFQ+ap/eStHYFpxDRWrEiCJadTnAwVKonGjn7urrmvE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAFevzVGtJV2Z/2dsb2JhbABbgwkySYMHuneBCA19FnSCIwEBAQMBAQEBIBEzBxALAgEIGAICBiACAgIlCxUQAgQTCIgBBgyqOJE6gSaNC3ICOIJRM2MDmG6QHIMRgWo+ X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228637121" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 15:45:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5SFjkO7020917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 15:45:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 10:45:46 -0500 From: "Cullen Jennings (fluffy)" To: "stir@ietf.org" Thread-Topic: [stir] Use of UUI for stir Thread-Index: AQHOccJ/0PZ2wL913kupYvRTF6Ucq5lLnWoA Date: Fri, 28 Jun 2013 15:45:46 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> <51C89C6E.1090603@dcrocker.net> <51C8C84C.3060204@cs.tcd.ie> <07318193-9FE9-427D-8FA6-1F510412D7CF@oracle.com> <51C9C79A.1010701@alum.mit.edu> In-Reply-To: <51C9C79A.1010701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.211] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [stir] Use of UUI for 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, 28 Jun 2013 15:45:54 -0000 DQpUZXN0aW5nIHdoaWxlIGRldmVsb3BpbmcgVklQUiBpbmRpY2F0ZWQgdGhhdCBVVUkgZG9lcyBu b3Qgc3Vydml2ZSBhbGwgdGhlIGNhcnJpZXIgdG8gY2FycmllciB0cmFuc2l0aW9ucy4gDQoNCk9u IEp1biAyNSwgMjAxMywgYXQgMTI6MzggUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5t aXQuZWR1PiB3cm90ZToNCg0KPiBPbiA2LzI1LzEzIDI6MTkgQU0sIEhhZHJpZWwgS2FwbGFuIHdy b3RlOg0KPiANCj4+IFRoYXQgZGVwZW5kcyAtIGlmIGl0J3MgbGl0ZXJhbGx5IGp1c3QgYSBQUkkg bGluayBiZXR3ZWVuIENoYXJsaWUgYW5kIERhdmUsIHdlIGNhbiB0dW5uZWwgdGhlIGluZm8gaW4g YW4gSVNVUCBVVUkuICBUaGVyZSdyZSBldmVuIHdheXMgb2YgZG9pbmcgdGhhdCB3aXRob3V0IHJl cXVpcmluZyB0aGUgUFJJIEdhdGV3YXkgdG8gYmUgdHJ1bHkgYXdhcmUgb2YgaXQgbm9yIG5lZWQg dG8gYmUgdXBncmFkZWQsIGRlcGVuZGluZyBvbiB0aGUgdmVuZG9ycyBpbnZvbHZlZC4gIElmIGl0 J3MgYSBmdWxsIFNTNyBjYXJyaWVyIGluIGJldHdlZW4gQ2hhcmxpZSBhbmQgRGF2ZSwgYnV0IGl0 J3MganVzdCBvbmUgU1M3IGNhcnJpZXIgY29ubmVjdGluZyB0aGVtLCB3ZSBtaWdodCBzdGlsbCBi ZSBhYmxlIHRvIHR1bm5lbCB0aGUgVVVJIHRocm91Z2guDQo+IA0KPiBJJ3ZlIHNlZW4gdGhpcyBt ZW50aW9uZWQgbXVsdGlwbGUgdGltZXMgb24gdGhpcyBsaXN0Lg0KPiANCj4gTGV0IHVzIG5vdCBm b3JnZXQgdGhhdCBVVUkgaXMgdGhlcmUgZm9yIG90aGVycyB0byB1c2UuDQo+IFdlIGhhdmUgdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWN1c3Mtc2lwLXV1aeKAjiB0aGF0IGRlZmluZXMg aG93IHRvIHVzZSB0aGlzIGluIFNJUCwgYW5kIHdoaWNoIGNhbiBiZSB0dW5uZWxlZCBpbiBTUzcu DQo+IA0KPiBJIGd1ZXNzIHRoaXMgZG9lc24ndCBwcmVjbHVkZSB1c2luZyBVVUkgZm9yIHN0aXIs IGJ1dCBpdCBjZXJ0YWlubHkgY29tcHJvbWlzZXMgaXQuDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1 bA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz dGlyIG1haWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQo= From ekr@rtfm.com Fri Jun 28 08:48: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 8577E21F9AC9 for ; Fri, 28 Jun 2013 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 yypENy39kEDs for ; Fri, 28 Jun 2013 08:48:08 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAF21F9AAC for ; Fri, 28 Jun 2013 08:48:06 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so1474068qcz.28 for ; Fri, 28 Jun 2013 08:48:05 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Y3Uklgpgu6UvOsGXIwJgJKDzVi1eJ6DJCc0qdiRkS9o=; b=EPdfluwjUOvw6OutjNoPgZAFYCWTSmnkdVFKTRAlMAB4Q0yzEP4Fq3TMeUHv+muDJL rB+BHYdEfeZAEYkw2AGucAKNwlpkPk6nKDvr3C3HAbo7WuyeuRgq2TDGxB3rehvaRePb KmQBUqr+IVaNqI69S5/0Y+zMWHCeIj26SihBHguUnry0t2KiKRMUTNNrDyhUM3l3rL/t czOQ1GdIgr0/7DttvSFIKZnzNJ8mc/5vd+UByIJ8pP/WGS+ANewMTZWUea+e/k5P7Xz6 PgL2mH//vD9eFVNyMIAyfD/xnFxVbZj2F6DQRzZeluDQ44GAdIvWvBpnHS2/+QNSSa/X CMng== X-Received: by 10.229.168.132 with SMTP id u4mr4167541qcy.73.1372434484930; Fri, 28 Jun 2013 08:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 08:47:24 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 08:47:24 -0700 Message-ID: To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8f6475b1f3bb0b04e038cdc5 X-Gm-Message-State: ALoCoQlU0UB5miTj1Ih214GHuxwVjv5CrJqw7ge0cOHg40luffhis5f8jxkZmG7mh1hoi72OpBS1 Cc: "Wendt, Chris" , Richard Shockey , stir@ietf.org, Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:48:14 -0000 --e89a8f6475b1f3bb0b04e038cdc5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 8:41 AM, Hadriel Kaplan wrote: > > On Jun 28, 2013, at 11:09 AM, Eric Rescorla wrote: > > > First, let me say that I'm not at all wedded to anything in the proposal > > that bears my name and that I presented at the original STIR meeting. > > That proposal was designed to match a specific set of needs and > > if those needs aren't needed, then so much the better. > > > > With that said, my impression going into that meeting and from the > > discussion so far was that in fact for the foreseeable future we are > > going to have environments where: > > > > (1) We want to have secure caller-id > > (2) We basically can't put anything meaningful in the messages that > > go from caller to callee (I hasten to add that I don't know anywhere > > near enough about SS7 to know if that's true, but that was my > > impression). > > > > If that's true, then it seems like we really should be considering some > > non-inband solution from the get-go. > > > > So, for the people who favor not doing a non-inband solution, do you > > think that one of the two claims above is untrue? Or do you just don't > > think it follows that we should be doing something about it? > > We had a long email debate about it, and it's not as simple as that. Even > if one only considers those two claims in isolation, it's not as simple as > "yes" or "no" to *either* of those claims. I would give you the > readers-digest version, but undoubtedly it would be a subjective view of > it, and would just open up the debate all over again. > Well, I did read the debate, but frankly, I didn't think it really was that responsive to this. So I actually do think it would be useful. > I think, though, that we reached consensus not to have it in the charter > for this BOF and WG formation; Is that actually true? It was also not my sense that there was consensus on this point. For instance, did I miss a message where Jon agreed to that? -Ekr --e89a8f6475b1f3bb0b04e038cdc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 28, 2013 at 8:41 AM, Hadriel Kaplan &= lt;hadriel.k= aplan@oracle.com> wrote:

On Jun 28, 2013, at 11:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> First, let me say that I'm not at all wedd= ed to anything in the proposal
> that bears my name and that I presented at the original STIR meeting.<= br> > That proposal was designed to match a specific set of needs and
> if those needs aren't needed, then so much the better.
>
> With that said, my impression going into that meeting and from the
> discussion so far was that in fact for the foreseeable future we are > going to have environments where:
>
> (1) We want to have secure caller-id
> (2) We basically can't put anything meaningful in the messages tha= t
> go from caller to callee (I hasten to add that I don't know anywhe= re
> near enough about SS7 to know if that's true, but that was my
> impression).
>
> If that's true, then it seems like we really should be considering= some
> non-inband solution from the get-go.
>
> So, for the people who favor not doing a non-inband solution, do you > think that one of the two claims above is untrue? Or do you just don&#= 39;t
> think it follows that we should be doing something about it?

We had a long email debate about it, and it's not as simple as th= at. =A0Even if one only considers those two claims in isolation, it's n= ot as simple as "yes" or "no" to *either* of those clai= ms. =A0I would give you the readers-digest version, but undoubtedly it woul= d be a subjective view of it, and would just open up the debate all over ag= ain.

Well, I did read the debate, but fra= nkly, I didn't think it really was that
responsive to t= his. So I actually do think it would be useful.


=A0
I think, though, that we reached consensus not to have it in the charter fo= r this BOF and WG formation;

Is that = actually true? It was also not my sense that there was consensus on this po= int.
For instance, did I miss a message where Jon agreed to that?

-Ekr

--e89a8f6475b1f3bb0b04e038cdc5-- From fluffy@cisco.com Fri Jun 28 08:48: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 1710321F9AAD for ; Fri, 28 Jun 2013 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Lsnj2YRQpLRB for ; Fri, 28 Jun 2013 08:48:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3598D21F994A for ; Fri, 28 Jun 2013 08:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1391; q=dns/txt; s=iport; t=1372434507; x=1373644107; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fEaklctKmBGd+HVbjT6opGytjQ61hJQ8q5pqdO+6LCw=; b=NP3K4siELGwB2HknDKddDRXa0EvTXGPk/Endimz/iyLbQQ007eDjtsnB 8tA0V8CaNBIzmPpJN+GaqBbXi77iVJHcpYKNUV7t62gjK6/KWe4llQLEc Lj3m+z6J5ZY1DFVgCB7sIHer/NODrO5qYDQndsP8YnqJUdqACs+d20W+h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMSvzVGtJV2Z/2dsb2JhbABSCYJge78GgQqBCYIjAQEBAwE6LRIQAgEIIhQQMiUCBA4FCIgBBrNxjhuBCAIxB4MEYwOpCoMRgWokGg X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="225687190" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 15:48:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5SFmQu9024830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 15:48:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 10:48:26 -0500 From: "Cullen Jennings (fluffy)" To: "stir@ietf.org" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObVQeoFFK+vgIykemupOR+95XPJk+y9aAgACHMgD//49rgIACHTwAgAPpuACAAKBAgIAAArwAgAAJJQCABhF+AA== Date: Fri, 28 Jun 2013 15:48:25 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.211] Content-Type: text/plain; charset="us-ascii" Content-ID: <9CA9232299383B4CA6C459C5A9C4355C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:48:33 -0000 On Jun 24, 2013, at 3:08 PM, Henning Schulzrinne wrote: >=20 > The main difference between the two STIR modes discussed is between the a= ctors involved and the likely deployment incentives. The in-band mechanism = is likely to be deployed by carriers, the out-of-band mechanism by end user= s, such as legitimate call centers (and smart phones), for a variety of rea= sons already discussed at length. I'm guessing that many of us are hopeful = that we'll get much closer to 100% coverage with two mechanisms than with o= ne. The incremental validation effort is pretty minimal, and different enti= ties have different incentives to deploy one or the other, possibly on diff= erent timelines. +1=20 I think we need both the modes to happen at same time as the incremental de= ployment of one greatly improves the chance of any deployment of the second= mode. And deployment of that second mode is how we can get to the very hig= h percentages of calls to have a valid identity. I also think the dual appr= oach will make it much easier to get to consensus on on the actually mechan= ism in the WG as we won't have the proponents of one type trying to turn th= e other type into the type they prefer.=20 I'd prefer the charter to be clear that both in-band and out-band was the i= ntended direction of the group.=20 Cullen From ekr@rtfm.com Fri Jun 28 08:49: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 0908421F9ACA for ; Fri, 28 Jun 2013 08:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 FhV6S+qzciAT for ; Fri, 28 Jun 2013 08:49:01 -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 696F421F8528 for ; Fri, 28 Jun 2013 08:49:01 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so747840qeb.1 for ; Fri, 28 Jun 2013 08:49:01 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=fO+J9jHNXFQHroVV+P2l7tQIh5ZrHQPrMWAGIIvLqNc=; b=FafuV/gf/j8B93CfEvTJjPmT3r+no5dEI+fz8WF5DEz/QXEN1FMX2b375jifrUKb4I zug629es8T/4QAb5/89u0ZQ4pOIBuOEKnMbBrqDhSieVhwGE9lI8WIwrlNRqKVHFwc/N CrFL0PSSDFndSVY6kjUxqzKKQaRxJA5C3PvvALhUwTsu/2/GY3lHNdmgs+pk2OvJQTFt yy80/VpZ94m94NMIDLyyH0zsY65SWMfiwUFs31/PjqhUpX31+GOafpv/25erQ+P1Kr0R tod+x/2DmktuDniZOysllv2d8RpAriHawgLpv0GSxoq24esKTBqIGsD1CiW+VsCOZvhn f0DQ== X-Received: by 10.49.132.41 with SMTP id or9mr17905096qeb.18.1372434540889; Fri, 28 Jun 2013 08:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 08:48:20 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 08:48:20 -0700 Message-ID: To: "PFAUTZ, PENN L" Content-Type: multipart/alternative; boundary=047d7beb99fa498f5204e038d125 X-Gm-Message-State: ALoCoQlhCZsE0RKDhtoS4BDuKw3XlJw/bKqF0Oew3yz+Xih+psGDZw+/CkGfIuTxYQz42xoiqz2B Cc: "Wendt, Chris" , Hadriel Kaplan , Richard Shockey , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 15:49:06 -0000 --047d7beb99fa498f5204e038d125 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 8:37 AM, PFAUTZ, PENN L wrote: > Eric:**** > > Here=92s the problem I see: The out of band solution assumes that there i= s > something at the terminating end that is able to make use of the out of > band mechanism. > Of course. > This is not going to be generally true until the circuit switched networ= k > is mostly retired; customers hanging off a circuit switch aren=92t going = to > be protected. > Why is that true? A huge fraction of circuit switched devices are now smartphones, which could absolutely make use of such a mechanism. In fact, that's precisely the environment for which the system in question was designed. -Ekr > **** > > Once we have end to end SIP we can do something in-band.**** > > People might like to have a rapid solution but I just don=92t see it > happening without major refits to the legacy network. So, I=92d prefer to > concentrate on getting things right in the new world, even if that world > isn=92t coming as soon as any of us would like.**** > > ** ** > > ** ** > > ** ** > > Penn Pfautz**** > > AT&T Access Management**** > > +1-732-420-4962**** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Eric Rescorla > *Sent:* Friday, June 28, 2013 11:10 AM > *To:* Richard Shockey > *Cc:* Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian > Rosen; Henning Schulzrinne > > *Subject:* Re: [stir] Out-of-band vs. in-band**** > > ** ** > > [Semi-randomly picking a message to reply to...]**** > > ** ** > > First, let me say that I'm not at all wedded to anything in the proposal*= * > ** > > that bears my name and that I presented at the original STIR meeting.**** > > That proposal was designed to match a specific set of needs and**** > > if those needs aren't needed, then so much the better.**** > > ** ** > > With that said, my impression going into that meeting and from the**** > > discussion so far was that in fact for the foreseeable future we are**** > > going to have environments where:**** > > ** ** > > (1) We want to have secure caller-id**** > > (2) We basically can't put anything meaningful in the messages that**** > > go from caller to callee (I hasten to add that I don't know anywhere**** > > near enough about SS7 to know if that's true, but that was my**** > > impression).**** > > ** ** > > If that's true, then it seems like we really should be considering some**= * > * > > non-inband solution from the get-go.**** > > ** ** > > So, for the people who favor not doing a non-inband solution, do you**** > > think that one of the two claims above is untrue? Or do you just don't***= * > > think it follows that we should be doing something about it?**** > > ** ** > > Thanks,**** > > -Ekr**** > > ** ** > > ** ** > > On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote:**** > > +1 as well ... take it out of the charter.**** > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of**= * > * > > Wendt, Chris > Sent: Tuesday, June 25, 2013 1:20 PM > To: **** > > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band**** > > +1 > > On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: > > >> If that's truly the case - that we plan to do an in-band first, and wh= en > that's done then an out-of-band one - then I propose we remove the > out-of-band from the charter. We can always re-charter and add new > deliverables when we're ready for an out-of-band mechanism; we re-charter > all the time in RAI groups. We might even decide by then that an > out-of-band mechanism should work very differently, or that defining one > isn't necessary, or that we don't have the right participants in the IETF > to > do so successfully. > >> > >> For now, by removing it from the charter, we can focus on one solution > and not have to debate about this aspect during the BOF nor WG meetings. = I > am very worried that we won't have a successful BOF - where I measure > "success" as reaching consensus to create a Working Group. Lengthy > microphone debates kill BOFs, in my experience. (and I recognize you and > Russ and others have seen far more BOFs than I have, so maybe I've just > been > to the wrong ones ;) > > > > > > +1. > > > > Narrow, clear focus. > > > > Good. > > > > 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 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir**** > > ** ** > --047d7beb99fa498f5204e038d125 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 28, 2013 at 8:37 AM, PFAUTZ, PENN L &= lt;pp3129@att.com&g= t; wrote:

Eric:

Here=92s the problem I se= e: The out of band solution assumes that there is something at the terminat= ing end that is able to make use of the out of band mechanism.


Of course.

=A0
=

This is not going t= o be generally true until the circuit switched network is mostly retired; c= ustomers hanging off a circuit switch aren=92t going to be protected.


Why is that true? A huge= fraction of circuit switched devices are now smartphones,
= which could absolutely make use of such a mechanism. In fact, that's pr= ecisely
the environment for which the system in question was designed.

-Ekr
=A0

Once we have end to end S= IP we can do something in-band.

People might like to have= a rapid solution but I just don=92t see it happening without major refits = to the legacy network. So, I=92d prefer to concentrate on getting things right in the new world, even if that world isn=92t coming as soon a= s any of us would like.

=A0<= /p>

=A0<= /p>

=A0<= /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-bounces@ietf.= org [mailto:= stir-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen; Henning Schu= lzrinne


Subject: Re: [stir] Out-of-band vs. in-band

=A0

[Semi-randomly picking a message to reply to...]<= /u>

=A0

First, let me say that I'm not at all wedded to = anything in the proposal

that bears my name and that I presented at the origi= nal STIR meeting.

That proposal was designed to match a specific set o= f needs and

if those needs aren't needed, then so much the b= etter.

=A0

With that said, my impression going into that meetin= g and from the

discussion so far was that in fact for the foreseeab= le future we are

going to have environments where:

=A0

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful i= n the messages that

go from caller to callee (I hasten to add that I don= 't know anywhere

near enough about SS7 to know if that's true, bu= t that was my

impression).

=A0

If that's true, then it seems like we really sho= uld be considering some

non-inband solution from the get-go.

=A0

So, for the people who favor not doing a non-inband = solution, do you

think that one of the two claims above is untrue? Or= do you just don't

think it follows that we should be doing something a= bout it?

=A0

Thanks,

-Ekr

=A0

=A0

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <= ;richard@shockey.us= > wrote:

+1 as well ... take it out of the charter.=


-----Original Message-----
From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbi= w.net>

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first= , and when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter. =A0We can always re-charter and add new
deliverables when we're ready for an out-of-band mechanism; we re-chart= er
all the time in RAI groups. =A0We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in th= e IETF to
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. = =A0I
am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. =A0Len= gthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just= been
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

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

=A0


--047d7beb99fa498f5204e038d125-- From michael.hammer@yaanatech.com Fri Jun 28 09:22: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 CB73C21F9A97 for ; Fri, 28 Jun 2013 09:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 2WrbzEJ-J9B9 for ; Fri, 28 Jun 2013 09:21: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 DAA8521F9AA2 for ; Fri, 28 Jun 2013 09:21: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; Fri, 28 Jun 2013 09:21:55 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgABQvIAAADC3FgAAJqlXAAAnMeAAADPu4sA== Date: Fri, 28 Jun 2013 16:21:54 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0EA94@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0E818@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: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01CE73E0.EDC9B190" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 16:22:03 -0000 ------=_NextPart_000_0011_01CE73E0.EDC9B190 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To prove that A exists is not a proof that B cannot exist. Second, your analogy relies on the partial discipline of the PSTN, that you also later note can be intentionally broken. What you don't yet recognize is that one can also unintentionally break things, unless some discipline removes the possibility (application of Murphy's Law). Third, you assume that all senders and receivers know all others a priori and that all know each other's conventions. You have not yet proven that is a reasonable assumption. While 100 years of history have allowed the accumulation of such knowledge in the PSTN, that doesn't transfer to the Internet. So, you need to get back to the fundamental question I am asking. What data does the function at the receive side need to rely on, and where does it get that information? The second you start assuming a priori out-of-band knowledge, this breaks. Unless you can show me how that knowledge can be learned upon receipt of the call, I am not buying it. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, June 28, 2013 8:26 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) But we have existence proof that cannot be the case: BBB could not possibly be expanding it to +1-703-555-1212 today, because by the time Dodge gets it they wouldn't be able to use it for the customer contact number. I set the analogy up this way because it's similar to phone calls: the From is in fact being used by the terminating carrier already right now; just like Dodge is already using the customer contact number in the analogy. For example when it reaches your phone, your phone displays some caller-id that has meaning to your phone/you, and it's not making the mistake of showing +1-703-555-1212 for calls from +1-603-555-1212 today. And the terminating carriers offer things like voicemail, CNAM, *69 callback, and billing records - and all those things work right now, and use the caller-id/From, and aren't getting confused about the area code. And in fact even the transit carriers (ie, BBB) often use the From phone number today - they use it for least-cost-routing for example, and billing. And the problem we're being told to go fix isn't that the terminating carriers can't figure out the From's E.164 numbers - they can - their problem is the caller-id's are being misrepresented on-purpose. Or to bring it back to the car analogy: Dodge isn't telling us "we can't figure out what the human put in AAA's original web-forms" - they're telling us people are *lying* when they fill out the web-forms. -hadriel On Jun 28, 2013, at 4:42 AM, Michael Hammer wrote: > Hadriel, > > Re: So AAA has some back-end systems that crunch this web-form input, > and those systems have no idea what format the Dodge Durango Division > (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do > know how the BBB expects it... STOP right there. > > That is an assumption that will often not hold. And is precisely my > problem. You assume that any given sender knows how to format for > every given recipient. > The issue of dots, dashes, or none is a sideshow. > > What if AAA decides to send as: From: 555-1212@AAA.com > > And if BBB looks at that and because BBB is in another area code > (703), it thinks that to extract, interpret, and expand it becomes > +1-703-555-1212 versus +1-603-555-1212 then you get errors. > Now compound that with different countries. You will gets lots of failures. > > The phone system routes on other headers, so what is in the From > header doesn't matter, so using that as an argument of "well the > system knows how to route" doesn't mean anything. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Hadriel Kaplan > Sent: Thursday, June 27, 2013 11:09 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > Maybe an analogy would help... > > Let's say you're a member of the New Hampshire division of the > American Automobile Association (AAA) in the USA. And let's say AAA > provides their members with a web-form to fill out if they want to > complain about a car design defect, and that AAA sends the complaint > on to the Better Business Bureau (BBB), who then sends the complaint on to the car manufacturer. > > So you go on the New Hampshire AAA website and fill out a form to > complain about your car, a Dodge Durango SUV - Dodge being a division > of Chrysler Car Company (CCC). The AAA web-form has a field asking > you what your phone-number is, so that you can be contacted for more > information if need be. And let's say since this website is for New > Hampshire members, that the web-form accepts a phone-number such as the literal string "555-1212". > There's no +1 needed because it's a US-based customer web-form, and no "603" > area-code because it knows you're from New Hampshire. > > So AAA has some back-end systems that crunch this web-form input, and > those systems have no idea what format the Dodge Durango Division > (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do > know how the BBB expects it, and the BBB expects it in the format > "603-555-1212", so the AAA back-end systems convert it to that and > send it to the BBB. The BBB likewise doesn't know Dodge's format, but > they know Chrysler and their format, so BBB's systems convert it to CCC's which is "+16035551212". > Chrysler then routes this complaint to Dodge Durango Division, who > happens to expect it as "+1.603.555.1212". > > So we have: > 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> > +1.603.555.1212@DDD.com > > None of these domains along the way are "confused" about what your > number really is, yet they all have a different syntactic > representation for it on-the-wire. > > So along comes the IETF, and we're worried that customer complaint > forms are getting received by car companies with spoofed customer > contact phone-numbers. > > What should we do? Should we say: "sorry, everyone's systems are > broken - please go fix them all to use a single syntax so we can sign > and verify it on both ends". That wouldn't happen, and isn't necessary. > > Instead, we're saying: "the forms are what they are to each domain and > we can't change that, but the New Hampshire AAA signing system has to > sign the > E.164 equivalent to what its form says, and the Dodge Durango Division > verification system has to verify the E.164 equivalent to what its > form says." > > It sounds silly, but it will work - both AAA and DDD do know what the > E.164 really is, regardless of what was put in the complaint form, and > despite the fact they have no idea what format/syntax the other one > uses. And the proof of that is that their complaint form mechanism > works today already; it's just getting spoofed with fake numbers. > > -hadriel > p.s. This was a fictional example - I have no idea if AAA provides > complaint web-forms or how they get to Dodge. > :) > > > On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > >> Mike, >> >> On 6/27/13 5:53 PM, Michael Hammer wrote: >>> Agree. But, I may be looking for something a little more stringent. >>> >>> First, you have to have a string that has a canonical form. >>> If it is not, then the string is likely something out of scope. >> >> The presumption is that the strings are whatever is in From and To, >> and > they they *are not* in canonical form. But it is assumed that the > signer can look at whatever is in the From and To it sees, and > generate a canonical form to sign. And that the verifier can look at > whatever is in the From and To *it* sees, and generate the canonical > form to verify. And that the get the same result! >> >> It is *not* assumed that the signer and the verifier are looking at >> the > identical thing. Each may be looking at a non-canonical form that fits > its local conventions, and that magic has resulted in the signer's > form being transformed into the verifier's form. >> >> It seems to me to be a lousy way to run a railroad, but that is what >> the > deployed systems apparently like to do. >> >> Thanks, >> Paul > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0011_01CE73E0.EDC9B190 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODE2MjE1M1owIwYJKoZIhvcNAQkEMRYEFCLwBram7UMw0vNtfdJr4xujWh3hMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAY1iZVYXykXA0xu5GspDSI4feSeGUq810OP5C4NUf irOoaWTgV+nKXIMt1VQ4K1RIfy9muTwDVBUvghwjvL/pqGK40IMdO/hwQPqZjdCM4UJnRUpGS97+ KKM8fROr+P49Qeh6uH9XQn2CfE8NKIVSlHGRzxrinV0pclwAG32yPhGrhEkHOffBdwNH4wB0nHf1 s3gURxszCFXOeVC8XrXtM/b8stp9Te0hvk44G1+XXkYOxutqcs7/abx5XDhjidk+xpjz7d2Yz9QC G6quXqfECIXBwILctR3oH3KdrpvhQXxqc5x0b98ZHq8ARB1L0SNulBkJam92e2ldDYGUkUvQKAAA AAAAAA== ------=_NextPart_000_0011_01CE73E0.EDC9B190-- From michael.hammer@yaanatech.com Fri Jun 28 09:28: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 A1DD521F843F for ; Fri, 28 Jun 2013 09:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 MJJ54hdi1EnX for ; Fri, 28 Jun 2013 09:28:23 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3B521F841B for ; Fri, 28 Jun 2013 09:28:23 -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, 28 Jun 2013 09:28:23 -0700 From: Michael Hammer To: Michael Hammer , "hadriel.kaplan@oracle.com" Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObZnb6m8qOmom8EmQkhTxasaT8pk/FLWAgAAHWYCAACgKgIABI2oAgACC9wCABJqygIAA53cAgAByg4CAACfSAIAACieAgAAVTgCAAAL+AP//qm/ggAFPO4CAAF9KAIAAA26AgACLhoCAAAMMAIAACYUA//+0pXCAAKXCAIAAR+WggACEfwCAABpsAP//xBlgABQvIAAADC3FgAAJqlXAAAnMeAAADPu4sAAZjLKQ Date: Fri, 28 Jun 2013 16:28:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0EB0F@EX2K10MB1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC0EA94@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0EA94@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.50.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0026_01CE73E1.D5193D40" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 16:28:30 -0000 ------=_NextPart_000_0026_01CE73E1.D5193D40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit One more point. The solution needs to handle calls from a domain that you have never heard from before. That domain may have just been created an hour before. We need a truly global solution when folks follow the IETF RFCs. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Friday, June 28, 2013 9:22 AM To: hadriel.kaplan@oracle.com Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) To prove that A exists is not a proof that B cannot exist. Second, your analogy relies on the partial discipline of the PSTN, that you also later note can be intentionally broken. What you don't yet recognize is that one can also unintentionally break things, unless some discipline removes the possibility (application of Murphy's Law). Third, you assume that all senders and receivers know all others a priori and that all know each other's conventions. You have not yet proven that is a reasonable assumption. While 100 years of history have allowed the accumulation of such knowledge in the PSTN, that doesn't transfer to the Internet. So, you need to get back to the fundamental question I am asking. What data does the function at the receive side need to rely on, and where does it get that information? The second you start assuming a priori out-of-band knowledge, this breaks. Unless you can show me how that knowledge can be learned upon receipt of the call, I am not buying it. Mike -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Friday, June 28, 2013 8:26 AM To: Michael Hammer Cc: stir@ietf.org Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) But we have existence proof that cannot be the case: BBB could not possibly be expanding it to +1-703-555-1212 today, because by the time Dodge gets it they wouldn't be able to use it for the customer contact number. I set the analogy up this way because it's similar to phone calls: the From is in fact being used by the terminating carrier already right now; just like Dodge is already using the customer contact number in the analogy. For example when it reaches your phone, your phone displays some caller-id that has meaning to your phone/you, and it's not making the mistake of showing +1-703-555-1212 for calls from +1-603-555-1212 today. And the terminating carriers offer things like voicemail, CNAM, *69 callback, and billing records - and all those things work right now, and use the caller-id/From, and aren't getting confused about the area code. And in fact even the transit carriers (ie, BBB) often use the From phone number today - they use it for least-cost-routing for example, and billing. And the problem we're being told to go fix isn't that the terminating carriers can't figure out the From's E.164 numbers - they can - their problem is the caller-id's are being misrepresented on-purpose. Or to bring it back to the car analogy: Dodge isn't telling us "we can't figure out what the human put in AAA's original web-forms" - they're telling us people are *lying* when they fill out the web-forms. -hadriel On Jun 28, 2013, at 4:42 AM, Michael Hammer wrote: > Hadriel, > > Re: So AAA has some back-end systems that crunch this web-form input, > and those systems have no idea what format the Dodge Durango Division > (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do > know how the BBB expects it... STOP right there. > > That is an assumption that will often not hold. And is precisely my > problem. You assume that any given sender knows how to format for > every given recipient. > The issue of dots, dashes, or none is a sideshow. > > What if AAA decides to send as: From: 555-1212@AAA.com > > And if BBB looks at that and because BBB is in another area code > (703), it thinks that to extract, interpret, and expand it becomes > +1-703-555-1212 versus +1-603-555-1212 then you get errors. > Now compound that with different countries. You will gets lots of failures. > > The phone system routes on other headers, so what is in the From > header doesn't matter, so using that as an argument of "well the > system knows how to route" doesn't mean anything. > > Mike > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf > Of Hadriel Kaplan > Sent: Thursday, June 27, 2013 11:09 PM > To: stir@ietf.org > Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) > > > Maybe an analogy would help... > > Let's say you're a member of the New Hampshire division of the > American Automobile Association (AAA) in the USA. And let's say AAA > provides their members with a web-form to fill out if they want to > complain about a car design defect, and that AAA sends the complaint > on to the Better Business Bureau (BBB), who then sends the complaint on to the car manufacturer. > > So you go on the New Hampshire AAA website and fill out a form to > complain about your car, a Dodge Durango SUV - Dodge being a division > of Chrysler Car Company (CCC). The AAA web-form has a field asking > you what your phone-number is, so that you can be contacted for more > information if need be. And let's say since this website is for New > Hampshire members, that the web-form accepts a phone-number such as the literal string "555-1212". > There's no +1 needed because it's a US-based customer web-form, and no "603" > area-code because it knows you're from New Hampshire. > > So AAA has some back-end systems that crunch this web-form input, and > those systems have no idea what format the Dodge Durango Division > (DDD) of Chrysler Car Company (CCC) expects to get it as. But they do > know how the BBB expects it, and the BBB expects it in the format > "603-555-1212", so the AAA back-end systems convert it to that and > send it to the BBB. The BBB likewise doesn't know Dodge's format, but > they know Chrysler and their format, so BBB's systems convert it to CCC's which is "+16035551212". > Chrysler then routes this complaint to Dodge Durango Division, who > happens to expect it as "+1.603.555.1212". > > So we have: > 555-1212@AAA.com -> 603-555-1212@BBB.com -> +16035551212@CCC.com -> > +1.603.555.1212@DDD.com > > None of these domains along the way are "confused" about what your > number really is, yet they all have a different syntactic > representation for it on-the-wire. > > So along comes the IETF, and we're worried that customer complaint > forms are getting received by car companies with spoofed customer > contact phone-numbers. > > What should we do? Should we say: "sorry, everyone's systems are > broken - please go fix them all to use a single syntax so we can sign > and verify it on both ends". That wouldn't happen, and isn't necessary. > > Instead, we're saying: "the forms are what they are to each domain and > we can't change that, but the New Hampshire AAA signing system has to > sign the > E.164 equivalent to what its form says, and the Dodge Durango Division > verification system has to verify the E.164 equivalent to what its > form says." > > It sounds silly, but it will work - both AAA and DDD do know what the > E.164 really is, regardless of what was put in the complaint form, and > despite the fact they have no idea what format/syntax the other one > uses. And the proof of that is that their complaint form mechanism > works today already; it's just getting spoofed with fake numbers. > > -hadriel > p.s. This was a fictional example - I have no idea if AAA provides > complaint web-forms or how they get to Dodge. > :) > > > On Jun 27, 2013, at 8:20 PM, Paul Kyzivat wrote: > >> Mike, >> >> On 6/27/13 5:53 PM, Michael Hammer wrote: >>> Agree. But, I may be looking for something a little more stringent. >>> >>> First, you have to have a string that has a canonical form. >>> If it is not, then the string is likely something out of scope. >> >> The presumption is that the strings are whatever is in From and To, >> and > they they *are not* in canonical form. But it is assumed that the > signer can look at whatever is in the From and To it sees, and > generate a canonical form to sign. And that the verifier can look at > whatever is in the From and To *it* sees, and generate the canonical > form to verify. And that the get the same result! >> >> It is *not* assumed that the signer and the verifier are looking at >> the > identical thing. Each may be looking at a non-canonical form that fits > its local conventions, and that magic has resulted in the signer's > form being transformed into the verifier's form. >> >> It seems to me to be a lousy way to run a railroad, but that is what >> the > deployed systems apparently like to do. >> >> Thanks, >> Paul > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0026_01CE73E1.D5193D40 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODE2MjgyMlowIwYJKoZIhvcNAQkEMRYEFAyt7t1dG/Ujke8eiRzEyuBAA6p2MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAHTxqYMYiacB9oTVPnEYhaR1zJeIDlm0fnQLrGB+X G3cpsY4BD7eGx0Iu/ygY97fq2vAt5Kmy4Tn5B0AkG176+1dqSNNkpxxIpreaSrmwnnRWnUbORUPZ 00xMsoYg1toZewiNijq8Yqd+N8MQcwtYIUlMah4npuSLIjinDZZH7/LMKORs8pSMejW524ILTLes ctkBTto4PBcLWw4U0iEN49kcthbzpGOJloThu71eg4wI7eNSWeDwVfJKRet9Wg+hD/c39E0VAA7z WQYRt+d8W8PxUdbx7E/JitPMfPtBJAqYh463f4ewa1+eaCJbEVjOSDFlmyk+txuJTofz7Z2HAAAA AAAAAA== ------=_NextPart_000_0026_01CE73E1.D5193D40-- From dhc@dcrocker.net Fri Jun 28 09:48: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 BAA6921F85BB for ; Fri, 28 Jun 2013 09:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 Ye53RPQIBsz1 for ; Fri, 28 Jun 2013 09:48:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0800021F85CC for ; Fri, 28 Jun 2013 09:48:07 -0700 (PDT) Received: from [100.130.129.135] ([206.29.182.247]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SGlq6G013123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Jun 2013 09:47:59 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----59LZY7S3MHT8B69EAU0XHD8UU2T6SY" From: Dave Crocket Date: Fri, 28 Jun 2013 09:47:47 -0700 To: Eric Rescorla , Hadriel Kaplan Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Jun 2013 09:48:02 -0700 (PDT) Cc: "Wendt, Chris" , Richard Shockey , stir@ietf.org, Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 16:48:24 -0000 ------59LZY7S3MHT8B69EAU0XHD8UU2T6SY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Forgive my confusion, but is Jon's agreement required, before being able to declare consensus? Eric Rescorla wrote: >On Fri, Jun 28, 2013 at 8:41 AM, Hadriel Kaplan >wrote: > >> >> On Jun 28, 2013, at 11:09 AM, Eric Rescorla wrote: >> >> > First, let me say that I'm not at all wedded to anything in the >proposal >> > that bears my name and that I presented at the original STIR >meeting. >> > That proposal was designed to match a specific set of needs and >> > if those needs aren't needed, then so much the better. >> > >> > With that said, my impression going into that meeting and from the >> > discussion so far was that in fact for the foreseeable future we >are >> > going to have environments where: >> > >> > (1) We want to have secure caller-id >> > (2) We basically can't put anything meaningful in the messages that >> > go from caller to callee (I hasten to add that I don't know >anywhere >> > near enough about SS7 to know if that's true, but that was my >> > impression). >> > >> > If that's true, then it seems like we really should be considering >some >> > non-inband solution from the get-go. >> > >> > So, for the people who favor not doing a non-inband solution, do >you >> > think that one of the two claims above is untrue? Or do you just >don't >> > think it follows that we should be doing something about it? >> >> We had a long email debate about it, and it's not as simple as that. >Even >> if one only considers those two claims in isolation, it's not as >simple as >> "yes" or "no" to *either* of those claims. I would give you the >> readers-digest version, but undoubtedly it would be a subjective view >of >> it, and would just open up the debate all over again. >> > >Well, I did read the debate, but frankly, I didn't think it really was >that >responsive to this. So I actually do think it would be useful. > > > > >> I think, though, that we reached consensus not to have it in the >charter >> for this BOF and WG formation; > > >Is that actually true? It was also not my sense that there was >consensus on >this point. >For instance, did I miss a message where Jon agreed to that? > >-Ekr > > >------------------------------------------------------------------------ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------59LZY7S3MHT8B69EAU0XHD8UU2T6SY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Forgive my confusion, but is Jon's agreement required, before being able to declare consensus?

Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, Jun 28, 2013 at 8:41 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

On Jun 28, 2013, at 11:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> First, let me say that I'm not at all wedded to anything in the proposal
> that bears my name and that I presented at the original STIR meeting.
> That proposal was designed to match a specific set of needs and
> if those needs aren't needed, then so much the better.
>
> With that said, my impression going into that meeting and from the
> discussion so far was that in fact for the foreseeable future we are
> going to have environments where:
>
> (1) We want to have secure caller-id
> (2) We basically can't put anything meaningful in the messages that
> go from caller to callee (I hasten to add that I don't know anywhere
> near enough about SS7 to know if that's true, but that was my
> impression).
>
> If that's true, then it seems like we really should be considering some
> non-inband solution from the get-go.
>
> So, for the people who favor not doing a non-inband solution, do you
> think that one of the two claims above is untrue? Or do you just don't
> think it follows that we should be doing something about it?

We had a long email debate about it, and it's not as simple as that.  Even if one only considers those two claims in isolation, it's not as simple as "yes" or "no" to *either* of those claims.  I would give you the readers-digest version, but undoubtedly it would be a subjective view of it, and would just open up the debate all over again.

Well, I did read the debate, but frankly, I didn't think it really was that
responsive to this. So I actually do think it would be useful.


 
I think, though, that we reached consensus not to have it in the charter for this BOF and WG formation;

Is that actually true? It was also not my sense that there was consensus on this point.
For instance, did I miss a message where Jon agreed to that?

-Ekr


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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------59LZY7S3MHT8B69EAU0XHD8UU2T6SY-- From wilhelm@wimmreuter.de Fri Jun 28 09:50: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 8816521F9BF6 for ; Fri, 28 Jun 2013 09:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ndD16pvirCWA for ; Fri, 28 Jun 2013 09:50:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2F21F9BF0 for ; Fri, 28 Jun 2013 09:50:19 -0700 (PDT) Received: from wwnet.ww (p5DE95F32.dip0.t-ipconnect.de [93.233.95.50]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M05tI-1TyQmi1qOq-00ubsm; Fri, 28 Jun 2013 18:50:16 +0200 Received: by wwnet.ww (Postfix, from userid 783) id CDE6FD266FF; Fri, 28 Jun 2013 18:50:15 +0200 (CEST) Received: from [10.200.122.210] (tmo-104-171.customers.d1-online.com [80.187.104.171]) (Authenticated sender: williw) by wwnet.ww (Postfix) with ESMTPSA id 45478D20749; Fri, 28 Jun 2013 18:50:10 +0200 (CEST) References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <39F78C74-63C8-4996-BF6F-E3CD98B7237E@wimmreuter.de> <3A8EBA70-002F-4E48-96E1-13B199BA59B8@oracle.com> In-Reply-To: <3A8EBA70-002F-4E48-96E1-13B199BA59B8@oracle.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <586BBEFE-72AB-4BB5-9FE2-0B73497EF370@wimmreuter.de> X-Mailer: iPhone Mail (9B206) From: williw Date: Fri, 28 Jun 2013 18:50:01 +0200 To: Hadriel Kaplan X-Provags-ID: V02:K0:nIfK1NpNmCsF90dgilH0r6L+ZT1VUzdF8zn4WqCtFb9 AQ/P1an2dixJkPNmmUTHfSAAC5p6UZi45NPvE3YdXDoMJ2j8+W R1i06+jgtigdJEpPal9/K3Wj9DIxYrcf42EpfZLjTaePqO+IDF nSCMR6aL1VZfpxS5UoZEsRC12EeePiOeOKoTAjBpEiXpD7Cskk Zl3AiEtHiyXhcurr92hCg8B7ILAOZZy3D1zhTuN1KVgzbRledv a1K+vNcQGHBg4cBfgc0ibch8Na21uQHu7TyFS+CDRU0mssAGmf 9J4RGb3TJ1faO6thwhvjZeagufwf/zwcXFJmT0dLpU7OfgW68d RYF0Z+dqTOToaN8LJ04qhtM+uL1gcBEfjNA5TZXgS Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 16:50:28 -0000 No Im serious and we shall learn little by little how to handle signatures f= or Internet services. Nevertheless I might need to learn how to finetune the possibilities a bit m= or. Hennings proposed multi (3) phase approach is definitely a good start we sha= ll think about. WIlli On 28.06.2013, at 17:07, Hadriel Kaplan wrote: >=20 > On Jun 28, 2013, at 2:56 AM, Wilhelm Wimmreuter wr= ote: >=20 >> Yes, this is a sample of legitimate Caller-ID spoofing ;-) >>=20 >> However, there are solutions for it. >> We can allow multiple signees for each phone number and thus there is a s= olution for re-signing as long as it is guaranteed that all signees are enro= lled and authenticated by the CA. This will be a classic PKI delegation and w= ill be perfectly valid. >>=20 >> As such, PKI can support our beloved hop-by-hop model as well. >> Of course, this will require that all "re-signees" are enrolled as a dele= gated authoritative signee for this particular number as well. So your exam= ple can be served well by PKI delegation models. >=20 > You're joking Willi, right? > I know you have a dry sense of humor, so I often can't tell when you're jo= king or not. > (sarcasm and dry humor doesn't always convey itself as such in email) >=20 > -hadriel >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From ekr@rtfm.com Fri Jun 28 09:55: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 E77A321F9A88 for ; Fri, 28 Jun 2013 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 dv8fNXNOTXLa for ; Fri, 28 Jun 2013 09:55:06 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 75CFF21F9A08 for ; Fri, 28 Jun 2013 09:54:43 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so1497011qcq.19 for ; Fri, 28 Jun 2013 09:54:42 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uCncr9fwIi7Bf9gpCFTqQfY8fWddT4ZAxllcI7GhUiA=; b=WH55DPp2O3FMHY+Kye6JPmhhsU9GUAII7a+xue6k7Wtb5UlflYN/92IQLL32GM/WZm wppjieE2C3hRIXWDa5ET3fb3cR0+56fisWMGoamuhZdXC597Lkm2B50upvz6H3DxClOi wo4kaYxffmicLQ9UMsBEqirGqBVx8w25YkJdColrkCU4Zux7MsFHMURo2myMAbB65ge/ SMUT4hiEXIilzZH7g1C0VPhX/gUuHd6Ia/jZjkj+/sh+Y8rewiRxkDlnASE4JjNc4McD kHNXV2ib3b9TuxH83untZ3GytkKLf9YS/Yw3PBqokEqZ8cXiccTj35JkSAfgOzIVUFgc 0iag== X-Received: by 10.224.174.138 with SMTP id t10mr19002265qaz.99.1372438482812; Fri, 28 Jun 2013 09:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 09:54:02 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 09:54:02 -0700 Message-ID: To: Dave Crocket Content-Type: multipart/alternative; boundary=20cf30334e033eae8004e039bcdd X-Gm-Message-State: ALoCoQm6qtL72KbD6fQFmUXKGiY2yIj+n1V5Hm4KLXX4LuoqhbZqJIOlZbVwgypPWeh1MwmMxbwc Cc: "Wendt, Chris" , Hadriel Kaplan , Richard Shockey , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 16:55:12 -0000 --20cf30334e033eae8004e039bcdd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 9:47 AM, Dave Crocket wrote: > Forgive my confusion, but is Jon's agreement required, before being able > to declare consensus? > Of course not. However, to my knowledge there also hasn't been a formal consensus call, so any assertions about consensus are merely individual's sense of the list. Did I miss such a call? -Ekr --20cf30334e033eae8004e039bcdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 9:47 AM, Dave Crocket <dhc@dcrocke= r.net> wrote:
Forgive my confusion, but is Jon&#= 39;s agreement required, before being able to declare consensus?

Of course not. However, to my knowle= dge there also hasn't been a
formal consensus call, so = any assertions about consensus are
merely individual's = sense of the list. Did I miss such a call?

-Ekr

<= br>
--20cf30334e033eae8004e039bcdd-- From dhc@dcrocker.net Fri Jun 28 10:07: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 C0A8121F9BB9 for ; Fri, 28 Jun 2013 10:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 Wy3DpmX3LwAo for ; Fri, 28 Jun 2013 10:07:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6521F9BB4 for ; Fri, 28 Jun 2013 10:07:16 -0700 (PDT) Received: from [100.130.129.135] ([206.29.182.247]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SH74DC013580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Jun 2013 10:07:11 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----7TL20FMXYW4LCM8LSIBXMM2FQDRSX3" From: Dave Crocker Date: Fri, 28 Jun 2013 10:06:56 -0700 To: Eric Rescorla Message-ID: <0cc7f70e-d968-450b-bd25-c84fb2dff81d@email.android.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Jun 2013 10:07:12 -0700 (PDT) Cc: "Wendt, Chris" , Hadriel Kaplan , Richard Shockey , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhc@dcrocker.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:07:21 -0000 ------7TL20FMXYW4LCM8LSIBXMM2FQDRSX3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Formal??? I think you are mistaking this with a working group. It is difficult for a group with no formal existance or structure to have formal decision making. On the other hand it is quite easy to review postings and see whether those participating in the discussion expressed views that converged in a way that could reasonably be called consensus. Eric Rescorla wrote: >On Fri, Jun 28, 2013 at 9:47 AM, Dave Crocket wrote: > >> Forgive my confusion, but is Jon's agreement required, before being >able >> to declare consensus? >> > >Of course not. However, to my knowledge there also hasn't been a >formal consensus call, so any assertions about consensus are >merely individual's sense of the list. Did I miss such a call? > >-Ekr -- Dave Crocker bbiw.net ------7TL20FMXYW4LCM8LSIBXMM2FQDRSX3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Formal??? I think you are mistaking this with a working group. It is difficult for a group with no formal existance or structure to have formal decision making.

On the other hand it is quite easy to review postings and see whether those participating in the discussion expressed views that converged in a way that could reasonably be called consensus.

Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jun 28, 2013 at 9:47 AM, Dave Crocket <dhc@dcrocker.net> wrote:
Forgive my confusion, but is Jon's agreement required, before being able to declare consensus?

Of course not. However, to my knowledge there also hasn't been a
formal consensus call, so any assertions about consensus are
merely individual's sense of the list. Did I miss such a call?

-Ekr



--
Dave Crocker
bbiw.net ------7TL20FMXYW4LCM8LSIBXMM2FQDRSX3-- From ekr@rtfm.com Fri Jun 28 10:13: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 C301921F9A8F for ; Fri, 28 Jun 2013 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 YibPV8pVn4sD for ; Fri, 28 Jun 2013 10:13:29 -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 D767221F9A2B for ; Fri, 28 Jun 2013 10:13:28 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so739573qaj.17 for ; Fri, 28 Jun 2013 10:13:28 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=PeZdE8NiOIEqlmqRnmv6m+YcEXHRVVEEzFZvYc42XkQ=; b=NEcmEIL0ARoZO5ooosYwYZ+0eumqZUSpkva136OOSfTRgJTKzmor4wl11lceKK34Ux VBGubtECt5PMy+7yNJsbtpTbeqok+PBuSQJpX0k6aLo1jtjBDOMCygwkIRsTJOSy5WDe 0Ejr+zXt2wdD6Inh3NK+0lisiE67z3DpXj683gHRXfK80QC6Xx7cFWyC5vlipFvHYwix S3QNZ5eUsmlX5DGR6e1XklqJdv1yKoplRb6wVmXsSGR4sOKFlKB7bGCWWA5wu47rAWM1 WK1UO376NgMa+eR3vE8+pLwtI9QMb/Lj0TzsGWISMZErUzCDy5F92p0yaGm8DQ/xUcS6 JlQA== X-Received: by 10.229.158.206 with SMTP id g14mr1258608qcx.22.1372439608282; Fri, 28 Jun 2013 10:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 10:12:48 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <0cc7f70e-d968-450b-bd25-c84fb2dff81d@email.android.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> <0cc7f70e-d968-450b-bd25-c84fb2dff81d@email.android.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 10:12:48 -0700 Message-ID: To: Dave Crocket Content-Type: multipart/alternative; boundary=f46d04446b4353d45904e039ff28 X-Gm-Message-State: ALoCoQmZnP0IEiXUv8P8VM5OXhMiJW3oFptWhtgywAdLDfvqj5G7wQ+WUgUPmQu4o/+gPP+cYFn2 Cc: "Wendt, Chris" , Hadriel Kaplan , Richard Shockey , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 17:13:35 -0000 --f46d04446b4353d45904e039ff28 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 10:06 AM, Dave Crocker wrote: > Formal??? I think you are mistaking this with a working group. It is > difficult for a group with no formal existance or structure to have formal > decision making. > > On the other hand it is quite easy to review postings and see whether > those participating in the discussion expressed views that converged in a > way that could reasonably be called consensus. > This seems like a digression, but surely you know well that mailing list volume is not necessarily an accurate gauge of the views of the group. Regardless, I don't think that there has been a sufficient level of demonstrated consensus to justify the assertion of Hadriel's to which I was replying. -Ekr --f46d04446b4353d45904e039ff28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 10:06 AM, Dave Crocker <dhc@dcro= cker.net> wrote:
Formal??? I think you are mistakin= g this with a working group. It is difficult for a group with no formal ex= istance or structure to have formal decision making.

On the other hand it is quite easy to review postings and see whether those= participating in the discussion expressed views that converged in a way th= at could reasonably be called consensus.

This seems like a digression, but surely you know well= that mailing
list volume is not necessarily an accurate ga= uge of the views of
the group.

Regardless, I don't think that there has been a sufficient l= evel of
demonstrated consensus to justify the assertion of = Hadriel's
to which I was replying.

-Ekr


--f46d04446b4353d45904e039ff28-- From richard@shockey.us Fri Jun 28 10:23: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 9B0F321F9A78 for ; Fri, 28 Jun 2013 10:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.372 X-Spam-Level: X-Spam-Status: No, score=-96.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MANGLED_PENIS=2.3, 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 iMsdcmiVJIpw for ; Fri, 28 Jun 2013 10:23:18 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 9A3FD21F9A70 for ; Fri, 28 Jun 2013 10:23:17 -0700 (PDT) Received: (qmail 25378 invoked by uid 0); 28 Jun 2013 17:22:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 28 Jun 2013 17:22:54 -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=b4/undxfmyjppouuAwkCvniwkEIFTH4gqfgFvxL5itg=; b=mg2rUOhgTIww88xk2HxpXhYDyn1+T1NUVxtVC55m21hFFgNn560tsOpPF/tp/dwmZaf+qSqnDTM/0wFFLK0CZqSnx4SNgy4DHhQFjp8jgT1rLS3dZUgeeh1lETv9p+q5; Received: from [72.66.111.124] (port=50096 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UscNo-0003Ty-Kz; Fri, 28 Jun 2013 11:22:53 -0600 From: "Richard Shockey" To: "'Eric Rescorla'" References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: Date: Fri, 28 Jun 2013 13:22:49 -0400 Message-ID: <006401ce7424$1e7371d0$5b5a5570$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CE7402.976B6EC0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NmYMB+nA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Dave Crocker' , 'Henning Schulzrinne' Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 17:23:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0065_01CE7402.976B6EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren't going to be protected. Why is that true? A huge fraction of circuit switched devices are now smartphones, which could absolutely make use of such a mechanism. In fact, that's precisely the environment for which the system in question was designed. [RS> ] Frankly I would doubt that. I would imagine the mobile operators and Apple would object to anything that creates more signaling over the air. Battery life. Its already an issue in VoLTE deployments. I have trouble imagining any E2E scenarios in a first phase deployment and Penn is absolutely correct that there are not going to be any major retrofits of the legacy networks, certainly not in North America. If the BOF is going to turn on in vs out of band vs both, historically we tend to note that the IETF works best when it builds on some success with one first. -Ekr Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don't see it happening without major refits to the legacy network. So, I'd prefer to concentrate on getting things right in the new world, even if that world isn't coming as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto: stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org ] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org ; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF to do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just been to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0065_01CE7402.976B6EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

This is not going to be generally true until the circuit switched = network is mostly retired; customers hanging off a circuit switch = aren’t going to be = protected.

 

Why is that true? A huge fraction of circuit switched = devices are now smartphones,

which could absolutely make use of such a mechanism. = In fact, that's precisely

the environment for which the system in question was = designed.

 

[RS> ]  Frankly I would doubt that.  I would imagine the = mobile operators and Apple would object to anything that creates more = signaling over the air.  Battery life. Its already an issue in = VoLTE deployments.  I have trouble imagining any E2E scenarios in a = first phase deployment and Penn is absolutely correct that there are not = going to be any major retrofits of the legacy networks, certainly not in = North America.

 

If the BOF is going to turn on in vs out of band vs both, = historically we tend to note that the IETF works best when it builds on = some success with one first.

 

 

 

-Ekr

 

Once we have end to end SIP we can do something = in-band.

People might like to have a rapid solution but I just don’t see = it happening without major refits to the legacy network. So, I’d = prefer to concentrate on getting things right in the new world, even if = that world isn’t coming as soon as any of us would = like.

 

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-49= 62

From:= = stir-bounces= @ietf.org = [mailto:stir-bounces= @ietf.org] On = Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 = AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel = Kaplan; stir@ietf.or= g; Dave = Crocker; Brian Rosen; Henning = Schulzrinne


Subject: Re: [stir] Out-of-band vs. = in-band

 <= /o:p>

[Semi-random= ly picking a message to reply to...]

 <= /o:p>

First, let = me say that I'm not at all wedded to anything in the = proposal

that bears = my name and that I presented at the original STIR = meeting.

That = proposal was designed to match a specific set of needs = and

if those = needs aren't needed, then so much the = better.

 <= /o:p>

With that = said, my impression going into that meeting and from = the

discussion = so far was that in fact for the foreseeable future we = are

going to = have environments where:

 <= /o:p>

(1) We want = to have secure caller-id

(2) We = basically can't put anything meaningful in the messages = that

go from = caller to callee (I hasten to add that I don't know = anywhere

near enough = about SS7 to know if that's true, but that was = my

impression).=

 <= /o:p>

If that's = true, then it seems like we really should be considering = some

non-inband = solution from the get-go.

 <= /o:p>

So, for the = people who favor not doing a non-inband solution, do = you

think that = one of the two claims above is untrue? Or do you just = don't

think it = follows that we should be doing something about = it?

 <= /o:p>

Thanks,=

-Ekr

 <= /o:p>

 <= /p>

On Wed, Jun = 26, 2013 at 8:33 AM, Richard Shockey <richard@shockey.us> wrote:

+1 as well = ... take it out of the charter.


-----Ori= ginal Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of

Wendt, = Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbiw.net>

Cc: stir@ietf.org; Brian = Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] = Out-of-band vs. in-band

+1

On= Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If = that's truly the case - that we plan to do an in-band first, and = when
that's done then an out-of-band one - then I propose we remove = the
out-of-band from the charter.  We can always re-charter and = add new
deliverables when we're ready for an out-of-band mechanism; = we re-charter
all the time in RAI groups.  We might even decide = by then that an
out-of-band mechanism should work very differently, = or that defining one
isn't necessary, or that we don't have the right = participants in the IETF to
do so = successfully.
>>
>> For now, by removing it from the = charter, we can focus on one solution
and not have to debate about = this aspect during the BOF nor WG meetings.  I
am very worried = that we won't have a successful BOF - where I = measure
"success" as reaching consensus to create a Working = Group.  Lengthy
microphone debates kill BOFs, in my experience. = (and I recognize you and
Russ and others have seen far more BOFs than = I have, so maybe I've just been
to the wrong ones = ;)
>
>
> +1.
>
> Narrow, clear = focus.
>
> Good.
>
> 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

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

 <= /o:p>

 

------=_NextPart_000_0065_01CE7402.976B6EC0-- From ekr@rtfm.com Fri Jun 28 10:30: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 9870721F9A78 for ; Fri, 28 Jun 2013 10:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.03 X-Spam-Level: X-Spam-Status: No, score=-100.03 tagged_above=-999 required=5 tests=[AWL=-2.946, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 vfWLT1Rx1jGX for ; Fri, 28 Jun 2013 10:29:52 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id BA0EA21F9130 for ; Fri, 28 Jun 2013 10:28:42 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so749532qab.5 for ; Fri, 28 Jun 2013 10:28:42 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=NS4tw4SRoqEOheqkcB6gqccmpzD693SXYvsWTgV5Cbg=; b=NvDyAlDdWInxsGMYCJG0jxyTn0ZTEjf95g8kffWY9YujsG+gh0TpDy73KHAdXl3qpy lKgycLHTPgz3i68VM7f91a1B8WxBzYQdJkt1d0F0PZsAyOYnnwfVDdbR89nSi9p5r8Rg ae0KYur99BqywL36yzNPwC+1uhmZrIilwsu1RALhrxZ0nQLo4CTn17S+Ph7Wq1HJTrQB 7z8EMoOhWG1xzqWnOXP6EnDhplryzTgbm/1xzNJZ7Rm/TseLkVgPCX490J6nwrReRF/Q u0WaxiaMcleZQwVjB7GACnJA3cWyzv7fpxMTb6TmZJYlnErJw7rc//iKA1DQiBfolVj2 TnCQ== X-Received: by 10.49.14.101 with SMTP id o5mr18463995qec.55.1372440522156; Fri, 28 Jun 2013 10:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 10:28:01 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <006401ce7424$1e7371d0$5b5a5570$@shockey.us> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> From: Eric Rescorla Date: Fri, 28 Jun 2013 10:28:01 -0700 Message-ID: To: Richard Shockey Content-Type: multipart/alternative; boundary=047d7b676b3ccc93ba04e03a35c3 X-Gm-Message-State: ALoCoQmpuVE1QL0H7E+z0nI+MWUfWw4PQtcotEMB7seWRMmHjAfc6u5mcX9vv7PKSTITSBRXFnoh Cc: "stir@ietf.org" , Dave Crocker , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 17:30:01 -0000 --047d7b676b3ccc93ba04e03a35c3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey wrote= : > ** ** > > ** ** > > **** > > This is not going to be generally true until the circuit switched network > is mostly retired; customers hanging off a circuit switch aren=92t going = to > be protected.**** > > ** ** > > Why is that true? A huge fraction of circuit switched devices are now > smartphones,**** > > which could absolutely make use of such a mechanism. In fact, that's > precisely**** > > the environment for which the system in question was designed.**** > > ** ** > > *[RS> ] Frankly I would doubt that. I would imagine the mobile > operators and Apple would object to anything that creates more signaling > over the air. Battery life. Its already an issue in VoLTE deployments. = I > have trouble imagining any E2E scenarios in a first phase deployment and > Penn is absolutely correct that there are not going to be any major > retrofits of the legacy networks, certainly not in North America.* > I'm really not following this. 1. We're talking about something on the order of 10KB of traffic/call. My iphone uses this much bandwidth every time it polls my email server. This has a trivial impact on battery life. 2. It doesn't need a retrofit of the network, just the phone software. That's the point. -Ekr --047d7b676b3ccc93ba04e03a35c3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <richard@shocke= y.us> wrote:

=A0<= /span>

=A0

=A0

This is not goi= ng to be generally true until the circuit switched network is mostly retire= d; customers hanging off a circuit switch aren=92t going to be protected.

=A0

<= /div>

Why is that true? A huge fraction of circu= it switched devices are now smartphones,

which could absolutely make use of such a mechanism. In fact, that's pr= ecisely

the environment = for which the system in question was designed.

=A0=

[RS> = ]=A0 Frankly I would doubt that.=A0 I would imagine the mobile operators an= d Apple would object to anything that creates more signaling over the air.= =A0 Battery life. Its already an issue in VoLTE deployments.=A0 I have trou= ble imagining any E2E scenarios in a first phase deployment and Penn is abs= olutely correct that there are not going to be any major retrofits of the l= egacy networks, certainly not in North America.

=A0

I'm re= ally not following this.

1. We're talking abou= t something on the order of 10KB of traffic/call.
My iphone uses this much bandwidth every time it polls my email
<= div>server. This has a trivial impact on battery life.

=
2. It doesn't need a retrofit of the network, just the phone= software.
That's the point.

-Ekr<= /div>

--047d7b676b3ccc93ba04e03a35c3-- From md3135@att.com Fri Jun 28 10:50: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 B24F921F9A83 for ; Fri, 28 Jun 2013 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 qB6kH9rn1ocC for ; Fri, 28 Jun 2013 10:49:55 -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 1C3AC21F9A96 for ; Fri, 28 Jun 2013 10:49:55 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 3cccdc15.2aaabe803940.6233201.00-562.17350708.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 17:49:55 +0000 (UTC) X-MXL-Hash: 51cdccc3023f4a07-c85c21053834d81be26d836f8876e976a2b533ea Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dbccdc15.0.6233032.00-360.17350186.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 17:49:54 +0000 (UTC) X-MXL-Hash: 51cdccc261aba248-0e442f58420af3ae70ee104a7ce8376ef5bc451f 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 r5SHnnrX011792; Fri, 28 Jun 2013 13:49:49 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5SHnbQt011671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 13:49:39 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 17:49:24 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 13:49:32 -0400 From: "DOLLY, MARTIN C" To: Richard Shockey Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQFSz1Hq9Ube0wumgUCN8mAR+HJszwI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NmYMB+nCAABm3Fw== Date: Fri, 28 Jun 2013 17:49:33 +0000 Message-ID: <173EA510-8540-4589-A94C-61409568E55C@att.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> , <006401ce7424$1e7371d0$5b5a5570$@shockey.us> In-Reply-To: <006401ce7424$1e7371d0$5b5a5570$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_173EA51085404589A94C61409568E55Cattcom_" 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=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=48vgC7mUAAAA:8 a=k7Ga1wGzA] X-AnalysisOut: [AAA:8 a=b8OvNEjoAAAA:8 a=og1UpytrIaw_XfuenBYA:9 a=pILNOxqG] X-AnalysisOut: [KmIA:10 a=iE9YWIBck50A:10 a=ClmATp4dOM8A:10 a=vRAbILRZcFsA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=fcAx7uNQz4EA:10 a=E1Snkw02GREA:10 ] X-AnalysisOut: [a=3t5khy7IeURX0fbY:21 a=gFZT219rksCiY_4R:21 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 ] X-AnalysisOut: [a=tXsnliwV7b4A:10 a=GPg3BXaDotkh6fK4:21 a=wRCMI2ajqNJJwgJ1] X-AnalysisOut: [:21 a=6qp_ugJgdFA00uBg:21] Cc: "stir@ietf.org" , Eric Rescorla , Dave Crocker , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 17:50:00 -0000 --_000_173EA51085404589A94C61409568E55Cattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No retrofits in legacy networks Martin Dolly AT&T Sent from my iPhone On Jun 28, 2013, at 1:23 PM, "Richard Shockey" > wrote: This is not going to be generally true until the circuit switched network i= s mostly retired; customers hanging off a circuit switch aren=92t going to = be protected. Why is that true? A huge fraction of circuit switched devices are now smart= phones, which could absolutely make use of such a mechanism. In fact, that's precis= ely the environment for which the system in question was designed. [RS> ] Frankly I would doubt that. I would imagine the mobile operators a= nd Apple would object to anything that creates more signaling over the air.= Battery life. Its already an issue in VoLTE deployments. I have trouble = imagining any E2E scenarios in a first phase deployment and Penn is absolut= ely correct that there are not going to be any major retrofits of the legac= y networks, certainly not in North America. If the BOF is going to turn on in vs out of band vs both, historically we t= end to note that the IETF works best when it builds on some success with on= e first. -Ekr Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don=92t see it happen= ing without major refits to the legacy network. So, I=92d prefer to concent= rate on getting things right in the new world, even if that world isn=92t c= oming as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave= Crocker; Brian Rosen; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henni= ng Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ 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_173EA51085404589A94C61409568E55Cattcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No retrofits in legacy networks

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <richard@shockey.us> wrote:

 <= /p>

 

 

This is not going to be generally true = until the circuit switched network is mostly retired; customers hanging off a circuit switch aren=92t going to be protected.

 

Why is that true? A huge fraction of circuit switche= d devices are now smartphones,

which could absolutely make use of such a mechanism.= In fact, that's precisely

the environment for which the system in question was= designed.

 

[RS> ]  Fra= nkly I would doubt that.  I would imagine the mobile operators and App= le would object to anything that creates more signaling over the air.  Battery life. Its already an issue in VoLTE deployments.  I have trou= ble imagining any E2E scenarios in a first phase deployment and Penn is abs= olutely correct that there are not going to be any major retrofits of the l= egacy networks, certainly not in North America.

 

If the BOF is going= to turn on in vs out of band vs both, historically we tend to note that th= e IETF works best when it builds on some success with one first.

 

 

 <= /p>

-Ekr

 

Once we have end to end SIP we can do s= omething in-band.

People might like to have a rapid solut= ion but I just don=92t see it happening without major refits to the legacy network. So, I=92d prefer to concentrate on getting things r= ight in the new world, even if that world isn=92t coming as soon as any of = us would like.

 

 

 

Penn Pfautz

AT&T Access Management

= 3;1-732-420-4962

From: stir-bounces@ietf.org [mailto:stir-bounces@iet= f.org] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; D= ave Crocker; Brian Rosen; Henning Schulzrinne


Subject: Re: [stir] Out-of-band vs. in-band

 

[Semi-randomly picking a message to reply to...]

 

First, let me say that I'm not at all wedded to anything in the pr= oposal

that bears my name and that I presented at the original STIR meeti= ng.

That proposal was designed to match a specific set of needs and

if those needs aren't needed, then so much the better.<= /p>

 

With that said, my impression going into that meeting and from the=

discussion so far was that in fact for the foreseeable future we a= re

going to have environments where:

 

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful in the messages tha= t

go from caller to callee (I hasten to add that I don't know anywhe= re

near enough about SS7 to know if that's true, but that was my=

impression).

 

If that's true, then it seems like we really should be considering= some

non-inband solution from the get-go.

 

So, for the people who favor not doing a non-inband solution, do y= ou

think that one of the two claims above is untrue? Or do you just d= on't

think it follows that we should be doing something about it?<= /o:p>

 

Thanks,

-Ekr

 

 

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <richard@shockey.us> wrote= :

+1 as well ... take it out of the charter.


-----Original Message-----
From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbi= w.net>

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first, an= d when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter.  We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups.  We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. &n= bsp;I
am very worried that we won't have a successful BOF - where I measure
"success" as reaching consensus to create a Working Group.  = Lengthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
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
https://www.ie= tf.org/mailman/listinfo/stir
--_000_173EA51085404589A94C61409568E55Cattcom_-- From ekr@rtfm.com Fri Jun 28 10: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 C2F2E21F9AA8 for ; Fri, 28 Jun 2013 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.539 X-Spam-Level: X-Spam-Status: No, score=-99.539 tagged_above=-999 required=5 tests=[AWL=-2.455, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 pgOGAjJeZHL6 for ; Fri, 28 Jun 2013 10:51:43 -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 EE36221F9A83 for ; Fri, 28 Jun 2013 10:51:40 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so765378qaj.3 for ; Fri, 28 Jun 2013 10:51:40 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=UiY+X5N3m48UYxZIxqqORZ4x0vLeo4wjeFA/0FG35Aw=; b=MtN6Th+hqpD+CFl1ZmFQwrW7B1fTIFN4ebSlDsSybKoEbksJsYGrbweRIMBl0qyldD yHO0SchaJKfO/8tI2RThn9Hc5mKh2/5Z/Ph1Yfg91ZzQyhUQzyZWhM3+SULpFgq46VZc F7w/AG1hECs6AFvbITyW5+wOEWWOOobQMLUzrUjHxwy4T7TVJ2d3l4xQjr4aGaTAsBTS lCAfhRpE3cT7MDFeAyqyDTzDxyqo2hH0BYOfsutkaelP2GbzuPKbeD09byrjA7fW/AkU 5KZwC3gtVKKUyPasv6pgIvpjZGoPHPov9r8YD1zMi0+AdU8WT6jxda6Duu1Yp8tzvuUw NWng== X-Received: by 10.224.174.138 with SMTP id t10mr19305678qaz.99.1372441900391; Fri, 28 Jun 2013 10:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 10:51:00 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <173EA510-8540-4589-A94C-61409568E55C@att.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <173EA510-8540-4589-A94C-61409568E55C@att.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 10:51:00 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=20cf30334e03f2a5f404e03a8706 X-Gm-Message-State: ALoCoQk8ZiPet3tx8xQ38fzUBzLIExfdDnqYDcx2ytRAE2E5CLaoUsyr2UZZ0fSs03mcHnCclaY9 Cc: "stir@ietf.org" , Henning Schulzrinne , Dave Crocker , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 17:51:48 -0000 --20cf30334e03f2a5f404e03a8706 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Could you perhaps elaborate? -Ekr On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C wrote: > No retrofits in legacy networks > > > Martin Dolly > AT&T > > Sent from my iPhone > > On Jun 28, 2013, at 1:23 PM, "Richard Shockey" wrote= : > > ** ** > > ** ** > > **** > > This is not going to be generally true until the circuit switched > network is mostly retired; customers hanging off a circuit switch aren=92= t > going to be protected.**** > > ** ** > > Why is that true? A huge fraction of circuit switched devices are now > smartphones,**** > > which could absolutely make use of such a mechanism. In fact, that's > precisely**** > > the environment for which the system in question was designed.**** > > ** ** > > *[RS> ] Frankly I would doubt that. I would imagine the mobile > operators and Apple would object to anything that creates more signaling > over the air. Battery life. Its already an issue in VoLTE deployments. = I > have trouble imagining any E2E scenarios in a first phase deployment and > Penn is absolutely correct that there are not going to be any major > retrofits of the legacy networks, certainly not in North America.* > > * * > > *If the BOF is going to turn on in vs out of band vs both, historically > we tend to note that the IETF works best when it builds on some success > with one first. * > > * * > > * * > > ** ** > > -Ekr**** > > **** > > Once we have end to end SIP we can do something in-band.**** > > People might like to have a rapid solution but I just don=92t see it > happening without major refits to the legacy network. So, I=92d prefer to > concentrate on getting things right in the new world, even if that world > isn=92t coming as soon as any of us would like.**** > > **** > > **** > > **** > > Penn Pfautz**** > > AT&T Access Management**** > > +1-732-420-4962**** > > *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf > Of *Eric Rescorla > *Sent:* Friday, June 28, 2013 11:10 AM > *To:* Richard Shockey > *Cc:* Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian > Rosen; Henning Schulzrinne**** > > > *Subject:* Re: [stir] Out-of-band vs. in-band**** > > **** > > [Semi-randomly picking a message to reply to...]**** > > **** > > First, let me say that I'm not at all wedded to anything in the proposal*= * > ** > > that bears my name and that I presented at the original STIR meeting.**** > > That proposal was designed to match a specific set of needs and**** > > if those needs aren't needed, then so much the better.**** > > **** > > With that said, my impression going into that meeting and from the**** > > discussion so far was that in fact for the foreseeable future we are**** > > going to have environments where:**** > > **** > > (1) We want to have secure caller-id**** > > (2) We basically can't put anything meaningful in the messages that**** > > go from caller to callee (I hasten to add that I don't know anywhere**** > > near enough about SS7 to know if that's true, but that was my**** > > impression).**** > > **** > > If that's true, then it seems like we really should be considering some**= * > * > > non-inband solution from the get-go.**** > > **** > > So, for the people who favor not doing a non-inband solution, do you**** > > think that one of the two claims above is untrue? Or do you just don't***= * > > think it follows that we should be doing something about it?**** > > **** > > Thanks,**** > > -Ekr**** > > **** > > **** > > On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote:**** > > +1 as well ... take it out of the charter.**** > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of**= * > * > > Wendt, Chris > Sent: Tuesday, June 25, 2013 1:20 PM > To: **** > > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band**** > > +1 > > On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: > > >> If that's truly the case - that we plan to do an in-band first, and wh= en > that's done then an out-of-band one - then I propose we remove the > out-of-band from the charter. We can always re-charter and add new > deliverables when we're ready for an out-of-band mechanism; we re-charter > all the time in RAI groups. We might even decide by then that an > out-of-band mechanism should work very differently, or that defining one > isn't necessary, or that we don't have the right participants in the IETF > to > do so successfully. > >> > >> For now, by removing it from the charter, we can focus on one solution > and not have to debate about this aspect during the BOF nor WG meetings. = I > am very worried that we won't have a successful BOF - where I measure > "success" as reaching consensus to create a Working Group. Lengthy > microphone debates kill BOFs, in my experience. (and I recognize you and > Russ and others have seen far more BOFs than I have, so maybe I've just > been > to the wrong ones ;) > > > > > > +1. > > > > Narrow, clear focus. > > > > Good. > > > > 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 > > _______________________________________________ > 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 > > --20cf30334e03f2a5f404e03a8706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Could you perhaps elaborate?

-Ekr=



On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C <md3135= @att.com> wrote:
No retrofits in legacy networks


Martin Dolly
AT&T=A0

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <richard@shockey.us> wrote:=

=A0<= /p>

=A0

=A0

This is not going to be g= enerally true until the circuit switched network is mostly retired; custome= rs hanging off a circuit switch aren=92t going to be protected.=

=A0

Why is that true? A huge fraction of circuit switche= d devices are now smartphones,

which could absolutely make use of such a mechanism.= In fact, that's precisely

the environment for which the system in question was= designed.

=A0

[RS> ]=A0 Frankl= y I would doubt that.=A0 I would imagine the mobile operators and Apple wou= ld object to anything that creates more signaling over the air.=A0 Battery life. Its already an issue in VoLTE deployments.=A0 I have trouble= imagining any E2E scenarios in a first phase deployment and Penn is absolu= tely correct that there are not going to be any major retrofits of the lega= cy networks, certainly not in North America.

=A0

If the BOF is going= to turn on in vs out of band vs both, historically we tend to note that th= e IETF works best when it builds on some success with one first.

=A0

=A0

=A0<= /p>

-Ekr

=A0

Once we have end to end S= IP we can do something in-band.

People might like to have= a rapid solution but I just don=92t see it happening without major refits to the legacy network. So, I=92d prefer to concentrate on getting things r= ight in the new world, even if that world isn=92t coming as soon as any of = us would like.

=A0<= /p>

=A0<= /p>

=A0<= /p>

Penn Pfautz

AT&T Access Management<= /span>

= +1-732-420-4962

From: stir-bounces@ietf.org [mailto:stir-bounces@iet= f.org] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; D= ave Crocker; Brian Rosen; Henning Schulzrinne


Subject: Re: [stir] Out-of-band vs. in-band

=A0

[Semi-randomly picking a message to reply to...]<= /u>

=A0

First, let me say that I'm not at all wedded to = anything in the proposal

that bears my name and that I presented at the origi= nal STIR meeting.

That proposal was designed to match a specific set o= f needs and

if those needs aren't needed, then so much the b= etter.

=A0

With that said, my impression going into that meetin= g and from the

discussion so far was that in fact for the foreseeab= le future we are

going to have environments where:

=A0

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful i= n the messages that

go from caller to callee (I hasten to add that I don= 't know anywhere

near enough about SS7 to know if that's true, bu= t that was my

impression).

=A0

If that's true, then it seems like we really sho= uld be considering some

non-inband solution from the get-go.

=A0

So, for the people who favor not doing a non-inband = solution, do you

think that one of the two claims above is untrue? Or= do you just don't

think it follows that we should be doing something a= bout it?

=A0

Thanks,

-Ekr

=A0

=A0

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <= ;richard@shockey.us= > wrote:

+1 as well ... take it out of the charter.=


-----Original Message-----
From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbi= w.net>

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first= , and when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter. =A0We can always re-charter and add new
deliverables when we're ready for an out-of-band mechanism; we re-chart= er
all the time in RAI groups. =A0We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in th= e IETF to
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. = =A0I
am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. =A0Len= gthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just= been
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

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

=A0

=A0

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

--20cf30334e03f2a5f404e03a8706-- From hadriel.kaplan@oracle.com Fri Jun 28 11: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 9275A21F9B00 for ; Fri, 28 Jun 2013 11:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 80iVc5+R6uTH for ; Fri, 28 Jun 2013 11:08:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED51621F9B12 for ; Fri, 28 Jun 2013 11:08:02 -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 r5SI7mNI001388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 18:07:49 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 r5SI7j0p026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 18:07: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 r5SI7jBv016399; Fri, 28 Jun 2013 18:07:45 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 11:07: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: Fri, 28 Jun 2013 14:07:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA91D96-B1AE-4FEE-9316-CB39046BD87D@oracle.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> <0cc7f70e-d968-450b-bd25-c84fb2dff81d@email.android.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Wendt, Chris" , Dave Crocket , Richard Shockey , "stir@ietf.org" , Dave Crocker , Brian Rosen , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 18:08:09 -0000 On Jun 28, 2013, at 1:12 PM, Eric Rescorla wrote: > This seems like a digression, but surely you know well that mailing > list volume is not necessarily an accurate gauge of the views of > the group. Unfortunately that's all we have to go on for now. There is no WG. = (fwiw, ISTM that many WG's in the IETF do in fact use email volume to = gauge things, but I digress...) > Regardless, I don't think that there has been a sufficient level of > demonstrated consensus to justify the assertion of Hadriel's > to which I was replying. That's fair, and I should have been much more careful with what I said - = I should have been clearer that I didn't mean unanimous agreement - we = definitely do NOT have that. I meant it more as a "I believe the = majority opinion is..." =20 And it's certainly possible my perception of a thinking even that is = wrong, and that we might be evenly divided instead, or that even the = majority might favor having both in-band and out-of-band in the charter. = I don't *think* that's the case, but I could be wrong. I will say though that if I count the multiple personalities/voices in = my head, I outnumber all of you. ;) -hadriel From hadriel.kaplan@oracle.com Fri Jun 28 11:21: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 538BE21F9AFB for ; Fri, 28 Jun 2013 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_57=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 xG+Q1amTCn+C for ; Fri, 28 Jun 2013 11:21:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4721F9A10 for ; Fri, 28 Jun 2013 11:21: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 r5SIERnN012230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 18:14:28 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 r5SIKjTN023844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 18:20:46 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 r5SIKjVq014815; Fri, 28 Jun 2013 18:20:45 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 11:20: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: Date: Fri, 28 Jun 2013 14:20:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 18:21:07 -0000 On Jun 28, 2013, at 11:45 AM, "Cullen Jennings (fluffy)" = wrote: > Just want to be clear we are trying to protect the caller-id for the = call. (i'd like to bold the "for the call" part of previous sentence).=20= >=20 No, we're not - or rather, that's not been the problem we've been asked = to solve, and not a problem that's actually occurring. We've been asked to solve the problem of bogus+spoofed caller-id's for = *call-initiating requests*. We have not been asked to solve a problem = of valid call requests with bogus media, we have not been asked to solve = a problem of valid calls being hijacked, we have not been asked to solve = a problem of valid calls being eavesdropped, we have not been asked to = solve a problem of valid calls being routed to the wrong participants, = etc. We've been asked to solve a real-world problem. We've been told to = solve it as quickly as possible. We've also essentially been told it = needs to be deployable by carriers, in such a way that they will *want* = to deploy it, because there's not going to be a legal mandate = rubber-stamping an IETF RFC and forcing the carriers to comply. (There = may be such a mandate in some countries someday, but not the one I live = in anyway... not in a short timeframe) I know we'd like to solve a lot of other problems at the same time, = because it's nice to kill two birds with one stone. But right now other = birds don't exist, and we have to throw the stone quickly before the = single bird gets away. And a bird in the hand is worth two in the bush. [heh, two proverbs linked together, cute eh? :) ] -hadriel From md3135@att.com Fri Jun 28 11:29: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 7FE9821F9BF5 for ; Fri, 28 Jun 2013 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 ikw3wp-QnUwJ for ; Fri, 28 Jun 2013 11:28:55 -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 DE8C321F9BE5 for ; Fri, 28 Jun 2013 11:28:54 -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 6e5ddc15.2aaaf1234940.5900196.00-582.16464251.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 18:28:54 +0000 (UTC) X-MXL-Hash: 51cdd5e630276df9-a29187a7b5b9ec5c8e07a7d4d796084c10cb2062 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 0e5ddc15.0.5900091.00-196.16463924.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 28 Jun 2013 18:28:53 +0000 (UTC) X-MXL-Hash: 51cdd5e524c52bb2-5096ed068fd1fbfb1669e2f7b26c36483e921740 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 r5SISjSV022496; Fri, 28 Jun 2013 14:28:48 -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 r5SISSMd022087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 14:28:38 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 18:28:05 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 14:28:13 -0400 From: "DOLLY, MARTIN C" To: Eric Rescorla Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQFSz1Hq9Ube0wumgUCN8mAR+HJszwI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NmYMB+nCAABm3F4AAQ3YA///HWB8= Date: Fri, 28 Jun 2013 18:28:12 +0000 Message-ID: <14C5B36A-7B13-4BFD-BFD5-0F80D2C1A948@att.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <173EA510-8540-4589-A94C-61409568E55C@att.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_14C5B36A7B134BFDBFD50F80D2C1A948attcom_" 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=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=5IsXbjgYAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=k7Ga1wGzAAAA:8 a=b8OvNEjoAAAA:8 a=og1UpytrIaw_Xfue] X-AnalysisOut: [nBYA:9 a=pILNOxqGKmIA:10 a=iE9YWIBck50A:10 a=ClmATp4dOM8A:] X-AnalysisOut: [10 a=Dd_Pfn986HIA:10 a=Hz7IrDYlS0cA:10 a=vRAbILRZcFsA:10 a] X-AnalysisOut: [=lZB815dzVvQA:10 a=fcAx7uNQz4EA:10 a=E1Snkw02GREA:10 a=3xq] X-AnalysisOut: [NYGcPuftUno9I:21 a=956xE70dlKvFibQF:21 a=_W_S_7VecoQA:10 a] X-AnalysisOut: [=tXsnliwV7b4A:10 a=oprjS1CXu9mkDWBu:21 a=Gi6zyoAt9aGPBeTA:] X-AnalysisOut: [21 a=cac3MYNq3Q6zV8d6:21] Cc: "stir@ietf.org" , Henning Schulzrinne , Dave Crocker , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 18:29:00 -0000 --_000_14C5B36A7B134BFDBFD50F80D2C1A948attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No changes to legacy switches to likely include CS-PS GW Martin Dolly AT&T Sent from my iPhone On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" > wrote: Could you perhaps elaborate? -Ekr On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C > wrote: No retrofits in legacy networks Martin Dolly AT&T Sent from my iPhone On Jun 28, 2013, at 1:23 PM, "Richard Shockey" > wrote: This is not going to be generally true until the circuit switched network i= s mostly retired; customers hanging off a circuit switch aren=92t going to = be protected. Why is that true? A huge fraction of circuit switched devices are now smart= phones, which could absolutely make use of such a mechanism. In fact, that's precis= ely the environment for which the system in question was designed. [RS> ] Frankly I would doubt that. I would imagine the mobile operators a= nd Apple would object to anything that creates more signaling over the air.= Battery life. Its already an issue in VoLTE deployments. I have trouble = imagining any E2E scenarios in a first phase deployment and Penn is absolut= ely correct that there are not going to be any major retrofits of the legac= y networks, certainly not in North America. If the BOF is going to turn on in vs out of band vs both, historically we t= end to note that the IETF works best when it builds on some success with on= e first. -Ekr Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don=92t see it happen= ing without major refits to the legacy network. So, I=92d prefer to concent= rate on getting things right in the new world, even if that world isn=92t c= oming as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave= Crocker; Brian Rosen; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henni= ng Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ 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_14C5B36A7B134BFDBFD50F80D2C1A948attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No changes to legacy switches to likely include CS-PS GW

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

Could you perhaps elaborate?

-Ekr



On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN = C <md3135@att.com&= gt; wrote:
No retrofits in legacy networks


Martin Dolly
AT&T 

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <richard@shockey.us> wrote:=

 

 

 

This is not going to be g= enerally true until the circuit switched network is mostly retired; custome= rs hanging off a circuit switch aren=92t going to be protected.

 

Why is that true? A huge fraction of circuit switche= d devices are now smartphones,

which could absolutely make use of such a mechanism.= In fact, that's precisely

the environment for which the system in question was= designed.

 

[RS> ]  Fra= nkly I would doubt that.  I would imagine the mobile operators and App= le would object to anything that creates more signaling over the air.  Battery life. Its already an issue in VoLTE deployments.  I have trou= ble imagining any E2E scenarios in a first phase deployment and Penn is abs= olutely correct that there are not going to be any major retrofits of the l= egacy networks, certainly not in North America.

 

If the BOF is going= to turn on in vs out of band vs both, historically we tend to note that th= e IETF works best when it builds on some success with one first.

 

 

 

-Ekr

 

Once we have end to end S= IP we can do something in-band.

People might like to have= a rapid solution but I just don=92t see it happening without major refits = to the legacy network. So, I=92d prefer to concentrate on getting things right in the new world, even if that world isn=92t coming as soon a= s any of us would like.

 

 

 

Penn Pfautz

AT&T Access Management<= /span>

= +1-732-420-4962

From: stir-bounces@ietf.org [mailto:stir-bounces@iet= f.org] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; D= ave Crocker; Brian Rosen; Henning Schulzrinne


Subject: Re: [stir] Out-of-band vs. in-band

 

[Semi-randomly picking a message to reply to...]<= /u>

 

First, let me say that I'm not at all wedded to anyt= hing in the proposal

that bears my name and that I presented at the origi= nal STIR meeting.

That proposal was designed to match a specific set o= f needs and

if those needs aren't needed, then so much the bette= r.

 

With that said, my impression going into that meetin= g and from the

discussion so far was that in fact for the foreseeab= le future we are

going to have environments where:

 

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful in th= e messages that

go from caller to callee (I hasten to add that I don= 't know anywhere

near enough about SS7 to know if that's true, but th= at was my

impression).

 

If that's true, then it seems like we really should = be considering some

non-inband solution from the get-go.

 

So, for the people who favor not doing a non-inband = solution, do you

think that one of the two claims above is untrue? Or= do you just don't

think it follows that we should be doing something a= bout it?

 

Thanks,

-Ekr

 

 <= /p>

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <= ;richard@shockey.us= > wrote:

+1 as well ... take it out of the charter.


-----Original Message-----
From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbi= w.net>

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first, an= d when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter.  We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups.  We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. &n= bsp;I
am very worried that we won't have a successful BOF - where I measure
"success" as reaching consensus to create a Working Group.  = Lengthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
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<= /span>
https://www.ietf.org/mailman/listinfo/stir

--_000_14C5B36A7B134BFDBFD50F80D2C1A948attcom_-- From michael.hammer@yaanatech.com Fri Jun 28 11:32: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 C306E21F9C05 for ; Fri, 28 Jun 2013 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_57=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 W4N8SYdfG0x7 for ; Fri, 28 Jun 2013 11:32:22 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id AD28821F9BCE for ; Fri, 28 Jun 2013 11:32:22 -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, 28 Jun 2013 11:32:20 -0700 From: Michael Hammer To: "hadriel.kaplan@oracle.com" , "fluffy@cisco.com" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qWRsjPKQFYKEy7+8dmUhlONZlLu4UAgAArZAD//42y0A== Date: Fri, 28 Jun 2013 18:32:19 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0EFC1@EX2K10MB1.corp.yaanatech.com> References: <42E86894-05FF-4D3B-B430-8E5660C44132@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.61] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C5_01CE73F3.25D8DEA0" MIME-Version: 1.0 Cc: "stir@ietf.org" , "jon.peterson@neustar.biz" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 18:32:26 -0000 ------=_NextPart_000_00C5_01CE73F3.25D8DEA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Perhaps the charter should have a requirement for extensibility. Then perhaps those other things can be added in later??? Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, June 28, 2013 11:21 AM To: Cullen Jennings (fluffy) Cc: stir@ietf.org; Jon Peterson Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) On Jun 28, 2013, at 11:45 AM, "Cullen Jennings (fluffy)" wrote: > Just want to be clear we are trying to protect the caller-id for the call. (i'd like to bold the "for the call" part of previous sentence). > No, we're not - or rather, that's not been the problem we've been asked to solve, and not a problem that's actually occurring. We've been asked to solve the problem of bogus+spoofed caller-id's for *call-initiating requests*. We have not been asked to solve a problem of valid call requests with bogus media, we have not been asked to solve a problem of valid calls being hijacked, we have not been asked to solve a problem of valid calls being eavesdropped, we have not been asked to solve a problem of valid calls being routed to the wrong participants, etc. We've been asked to solve a real-world problem. We've been told to solve it as quickly as possible. We've also essentially been told it needs to be deployable by carriers, in such a way that they will *want* to deploy it, because there's not going to be a legal mandate rubber-stamping an IETF RFC and forcing the carriers to comply. (There may be such a mandate in some countries someday, but not the one I live in anyway... not in a short timeframe) I know we'd like to solve a lot of other problems at the same time, because it's nice to kill two birds with one stone. But right now other birds don't exist, and we have to throw the stone quickly before the single bird gets away. And a bird in the hand is worth two in the bush. [heh, two proverbs linked together, cute eh? :) ] -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_00C5_01CE73F3.25D8DEA0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODE4MzIxOFowIwYJKoZIhvcNAQkEMRYEFBouV3zRdIZAMktmiwT2arRZAsuyMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWUtng2WfZU2I64x+tQ1svu6dZL0rPQ6NWpEY/MzR Aa6w5hAQ8Ej5FPDE594P0gkFs+hiWyfU9CMa8QrDlkOa6uL9yx4Dy83vBZKg6r9sQYLhbauRtMiB nsz4a/P8inQC4UQ9uujfIeFsGbpWOoez/ydk4sapr2rYMhxhHfgt3JCcUIv62OjCoUOL3DsH1DN5 /F2tFYm/B9Us7qEhQ+HFmvww8f5MnjhYR5fCFudol+lJKnuT+RHyy86juVduGawX83LUHc1pXYgx ddYomeUw0V2b99Og3sBoVTvzbVnNgRNpIBEBJQV04TPz2yyaiL/1s73f/IoNwsTtdZEPVDqr5AAA AAAAAA== ------=_NextPart_000_00C5_01CE73F3.25D8DEA0-- From ekr@rtfm.com Fri Jun 28 11:40: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 3D5C821F99AA for ; Fri, 28 Jun 2013 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.188 X-Spam-Level: X-Spam-Status: No, score=-99.188 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 x9be1UdMMhrS for ; Fri, 28 Jun 2013 11:39:56 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0EA21F9246 for ; Fri, 28 Jun 2013 11:39:56 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so1558244qcx.22 for ; Fri, 28 Jun 2013 11:39: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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=nsXn34TtkwPDx+/A+oWqm7WnMTHaRzqWM0OsDwlvH0E=; b=QtujGp4iV1Uh4TmcGKFSRQ6CZFRo7lvCdxYOJXqkm6/bKxXgC4xKhgDJhW8UBy+1Ry a5t+P6DmWdHW5NSwjKLHc55MfM/pro3INyHvp/uqa39WrZ8UYTAh2ROMi1Ohz6t5Omd+ 73QQCEsxDgI/JXKoArqTF6ewR3LPvEPaZeYn32ergGjFFhqv4DOGBnnohGhiMrNZ2oSB 8WSowgWpV+sTKDFguAoD6yIDfqs3J82hFxQoRZ7k48mELmFG8OeM5KEzZNVkySRpQkVr zIoYsEpzJStlRJEyUX8Ti1TYpDP52ebKjxBqpgwb0I0tlwHwq1BnxBd7PKz/pGw6EUYN FHbw== X-Received: by 10.49.98.138 with SMTP id ei10mr18905227qeb.3.1372444795849; Fri, 28 Jun 2013 11:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.35.226 with HTTP; Fri, 28 Jun 2013 11:39:15 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: <14C5B36A-7B13-4BFD-BFD5-0F80D2C1A948@att.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <173EA510-8540-4589-A94C-61409568E55C@att.com> <14C5B36A-7B13-4BFD-BFD5-0F80D2C1A948@att.com> From: Eric Rescorla Date: Fri, 28 Jun 2013 11:39:15 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7bdc832c87dfed04e03b344e X-Gm-Message-State: ALoCoQn2FW/d+WV9W+hglZtVbgTTZtvS181u/aYuB/TVoyLI6vKTg/+ctBazYVTnO+4QlMYkxFOV Cc: "stir@ietf.org" , Henning Schulzrinne , Dave Crocker , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 18:40:01 -0000 --047d7bdc832c87dfed04e03b344e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sure, I think that's consistent with that I'm saying. -Ekr On Fri, Jun 28, 2013 at 11:28 AM, DOLLY, MARTIN C wrote: > No changes to legacy switches to likely include CS-PS GW > > > Martin Dolly > AT&T > > Sent from my iPhone > > On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" wrote: > > Could you perhaps elaborate? > > -Ekr > > > > On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C wrote: > >> No retrofits in legacy networks >> >> >> Martin Dolly >> AT&T >> >> Sent from my iPhone >> >> On Jun 28, 2013, at 1:23 PM, "Richard Shockey" >> wrote: >> >> ** ** >> >> ** ** >> >> **** >> >> This is not going to be generally true until the circuit switched >> network is mostly retired; customers hanging off a circuit switch aren= =92t >> going to be protected.**** >> >> ** ** >> >> Why is that true? A huge fraction of circuit switched devices are now >> smartphones,**** >> >> which could absolutely make use of such a mechanism. In fact, that's >> precisely**** >> >> the environment for which the system in question was designed.**** >> >> ** ** >> >> *[RS> ] Frankly I would doubt that. I would imagine the mobile >> operators and Apple would object to anything that creates more signaling >> over the air. Battery life. Its already an issue in VoLTE deployments. = I >> have trouble imagining any E2E scenarios in a first phase deployment and >> Penn is absolutely correct that there are not going to be any major >> retrofits of the legacy networks, certainly not in North America.* >> >> * * >> >> *If the BOF is going to turn on in vs out of band vs both, historically >> we tend to note that the IETF works best when it builds on some success >> with one first. * >> >> * * >> >> * * >> >> ** ** >> >> -Ekr**** >> >> **** >> >> Once we have end to end SIP we can do something in-band.**** >> >> People might like to have a rapid solution but I just don=92t see it >> happening without major refits to the legacy network. So, I=92d prefer t= o >> concentrate on getting things right in the new world, even if that world >> isn=92t coming as soon as any of us would like.**** >> >> **** >> >> **** >> >> **** >> >> Penn Pfautz**** >> >> AT&T Access Management**** >> >> +1-732-420-4962**** >> >> *From:* stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] *On Behalf >> Of *Eric Rescorla >> *Sent:* Friday, June 28, 2013 11:10 AM >> *To:* Richard Shockey >> *Cc:* Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian >> Rosen; Henning Schulzrinne**** >> >> >> *Subject:* Re: [stir] Out-of-band vs. in-band**** >> >> **** >> >> [Semi-randomly picking a message to reply to...]**** >> >> **** >> >> First, let me say that I'm not at all wedded to anything in the proposal= * >> *** >> >> that bears my name and that I presented at the original STIR meeting.***= * >> >> That proposal was designed to match a specific set of needs and**** >> >> if those needs aren't needed, then so much the better.**** >> >> **** >> >> With that said, my impression going into that meeting and from the**** >> >> discussion so far was that in fact for the foreseeable future we are**** >> >> going to have environments where:**** >> >> **** >> >> (1) We want to have secure caller-id**** >> >> (2) We basically can't put anything meaningful in the messages that**** >> >> go from caller to callee (I hasten to add that I don't know anywhere**** >> >> near enough about SS7 to know if that's true, but that was my**** >> >> impression).**** >> >> **** >> >> If that's true, then it seems like we really should be considering some*= * >> ** >> >> non-inband solution from the get-go.**** >> >> **** >> >> So, for the people who favor not doing a non-inband solution, do you**** >> >> think that one of the two claims above is untrue? Or do you just don't**= * >> * >> >> think it follows that we should be doing something about it?**** >> >> **** >> >> Thanks,**** >> >> -Ekr**** >> >> **** >> >> **** >> >> On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey >> wrote:**** >> >> +1 as well ... take it out of the charter.**** >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of*= * >> ** >> >> Wendt, Chris >> Sent: Tuesday, June 25, 2013 1:20 PM >> To: **** >> >> Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne >> Subject: Re: [stir] Out-of-band vs. in-band**** >> >> +1 >> >> On Jun 25, 2013, at 1:00 PM, Dave Crocker wrote: >> >> >> If that's truly the case - that we plan to do an in-band first, and >> when >> that's done then an out-of-band one - then I propose we remove the >> out-of-band from the charter. We can always re-charter and add new >> deliverables when we're ready for an out-of-band mechanism; we re-charte= r >> all the time in RAI groups. We might even decide by then that an >> out-of-band mechanism should work very differently, or that defining one >> isn't necessary, or that we don't have the right participants in the IET= F >> to >> do so successfully. >> >> >> >> For now, by removing it from the charter, we can focus on one solutio= n >> and not have to debate about this aspect during the BOF nor WG meetings. >> I >> am very worried that we won't have a successful BOF - where I measure >> "success" as reaching consensus to create a Working Group. Lengthy >> microphone debates kill BOFs, in my experience. (and I recognize you and >> Russ and others have seen far more BOFs than I have, so maybe I've just >> been >> to the wrong ones ;) >> > >> > >> > +1. >> > >> > Narrow, clear focus. >> > >> > Good. >> > >> > 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 >> >> _______________________________________________ >> 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 >> >> > --047d7bdc832c87dfed04e03b344e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Sure, I think that's consistent with that I'm sayi= ng.

-Ekr



On Fri, Jun 28, 2013 a= t 11:28 AM, DOLLY, MARTIN C <md3135@att.com> wrote:
No changes to legacy switches to likely include CS-PS GW


Martin Dolly
AT&T=A0

Sent from my iPhone

On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

Could you perhaps elaborate?

-Ekr



On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN = C <md3135@att.com&= gt; wrote:
No retrofits in legacy networks


Martin Dolly
AT&T=A0

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <richard@shockey.us> wrote:=

=A0<= /p>

=A0

=A0

This is not going to be g= enerally true until the circuit switched network is mostly retired; custome= rs hanging off a circuit switch aren=92t going to be protected.

=A0

Why is that true? A huge fraction of circuit switche= d devices are now smartphones,

which could absolutely make use of such a mechanism.= In fact, that's precisely

the environment for which the system in question was= designed.

=A0

[RS> ]=A0 Frankl= y I would doubt that.=A0 I would imagine the mobile operators and Apple wou= ld object to anything that creates more signaling over the air.=A0 Battery life. Its already an issue in VoLTE deployments.=A0 I have trouble= imagining any E2E scenarios in a first phase deployment and Penn is absolu= tely correct that there are not going to be any major retrofits of the lega= cy networks, certainly not in North America.

=A0

If the BOF is going= to turn on in vs out of band vs both, historically we tend to note that th= e IETF works best when it builds on some success with one first.

=A0

=A0

=A0<= /p>

-Ekr

=A0

Once we have end to end S= IP we can do something in-band.

People might like to have= a rapid solution but I just don=92t see it happening without major refits = to the legacy network. So, I=92d prefer to concentrate on getting things right in the new world, even if that world isn=92t coming as soon a= s any of us would like.

=A0<= /p>

=A0<= /p>

=A0<= /p>

Penn Pfautz

AT&T Access Management<= /span>

= +1-732-420-4962

From: stir-bounces@ietf.org [mailto:stir-bounces@iet= f.org] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; D= ave Crocker; Brian Rosen; Henning Schulzrinne


Subject: Re: [stir] Out-of-band vs. in-band

=A0

[Semi-randomly picking a message to reply to...]<= /u>

=A0

First, let me say that I'm not at all wedded to = anything in the proposal

that bears my name and that I presented at the origi= nal STIR meeting.

That proposal was designed to match a specific set o= f needs and

if those needs aren't needed, then so much the b= etter.

=A0

With that said, my impression going into that meetin= g and from the

discussion so far was that in fact for the foreseeab= le future we are

going to have environments where:

=A0

(1) We want to have secure caller-id

(2) We basically can't put anything meaningful i= n the messages that

go from caller to callee (I hasten to add that I don= 't know anywhere

near enough about SS7 to know if that's true, bu= t that was my

impression).

=A0

If that's true, then it seems like we really sho= uld be considering some

non-inband solution from the get-go.

=A0

So, for the people who favor not doing a non-inband = solution, do you

think that one of the two claims above is untrue? Or= do you just don't

think it follows that we should be doing something a= bout it?

=A0

Thanks,

-Ekr

=A0

=A0

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <= ;richard@shockey.us= > wrote:

+1 as well ... take it out of the charter.=


-----Original Message-----
From: stir-bounc= es@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbi= w.net>

Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

On Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If that's truly the case - that we plan to do an in-band first= , and when
that's done then an out-of-band one - then I propose we remove the
out-of-band from the charter. =A0We can always re-charter and add new
deliverables when we're ready for an out-of-band mechanism; we re-chart= er
all the time in RAI groups. =A0We might even decide by then that an
out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in th= e IETF to
do so successfully.
>>
>> For now, by removing it from the charter, we can focus on one solu= tion
and not have to debate about this aspect during the BOF nor WG meetings. = =A0I
am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. =A0Len= gthy
microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just= been
to the wrong ones ;)
>
>
> +1.
>
> Narrow, clear focus.
>
> Good.
>
> 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
ht= tps://www.ietf.org/mailman/listinfo/stir

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

=A0

=A0

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


--047d7bdc832c87dfed04e03b344e-- From richard@shockey.us Fri Jun 28 11:45: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 583BC21F9AC5 for ; Fri, 28 Jun 2013 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.539 X-Spam-Level: X-Spam-Status: No, score=-96.539 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 2oshwE5c9oJX for ; Fri, 28 Jun 2013 11:44:58 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 1995521F9A87 for ; Fri, 28 Jun 2013 11:44:54 -0700 (PDT) Received: (qmail 6183 invoked by uid 0); 28 Jun 2013 18:44:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 28 Jun 2013 18:44:31 -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=acTEfwZYU0FzAaW+Kr4PjHAlF+LYpRr3M5E+CwlFsI4=; b=QhOwgUCtWn/2wBzuwfQGTsbOxUo2nbJpAxuqeTvJRHAS1LRba6QzHOi7na2A1O+Kl9C+uwr/5siWtX1cnZlN89frTs1R6MlzyB7IuoS6g0seTfLthB3dNb5oOMEXc4RH; Received: from [72.66.111.124] (port=50593 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Usdeo-00056K-F0; Fri, 28 Jun 2013 12:44:30 -0600 From: "Richard Shockey" To: "'Eric Rescorla'" , "'DOLLY, MARTIN C'" References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <173EA510-8540-4589-A94C-61409568E55C@att.com> In-Reply-To: Date: Fri, 28 Jun 2013 14:44:28 -0400 Message-ID: <00c101ce742f$85c1ab30$91450190$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01CE740D.FEB31870" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSz1HqEPsK2rOmM+sJgaXsYRJDIQI7uFAkAj6JaWgCF6RaiAKs8NY7AY4htgACFA+BuwE/ky+fAYPBB5cCAKnRJAFR8nnJAMFBynkCP03DuQH7I00NAlbZzeMBErslFAJFH8RxmVWrIUA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org, 'Dave Crocker' , 'Henning Schulzrinne' Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 18:45:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C2_01CE740D.FEB31870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is perfectly clear to those of us that have some intimate knowledge of North American carrier networks that neither the Incumbent LEC's , CLEC's nor the existing mobile operators will not make any new, much less incremental investments in TDM infrastructures. Go try and get some parts for a DMS 500 or 5ESS switch these days. All of it is gradually moving to SIP/IMS architectures. Cable, with some exceptions, has never relied on TDM in the core. There is some chance of implementation at the Gateways where SIP/TDM meet but that is another issue. http://www.fiercebroadbandwireless.com/story/t-wants-fccs-blessing-shut-down -pstn/2010-01-03 That said there is a staggering amount of SIP, SIP Interconnection AND DNS/ENUM btw in all NA carrier networks especially those that support SIP Trunking in the enterprise. Existing VZ FIOS and ATT uVerse networks use SIP/IMS in the core but the legacy handsets in the home are treated as B2BUA. Europe is somewhat behind but there are similar trends there. FCC Form 477 data now indicates that about 1/3 of all US Voice is SIP/IMS based but not fully SIP/IMS interconnected. Most of it is converted to TDM for interconnection for a lot of regulatory reasons I won't bore you with. (Section 251 of Act) All of the existing mobile CDMA/GSM networks still rely on TDM switches for the Voice service. That is going to change in 18-48 months as IMS based VoLTE rolls out so a handset tablet solution MAY be possible then. Those existing C5 switches in the mobile networks will be phased out within 5 years or so since the mobile operators want to refarm the existing spectrum to LTE. In fact your scenario won't work on the any existing Version or Sprint networks since CDMA does not allow for WIFI access and voice at the same time. Sorry Marty and Penn are right. The point Hadriel and I have been trying to make is the STIR solution(s) selected actually have to confront the reality of what can and will deploy given carrier capital budgets and overall long term strategy. The argument is that if out of band will have a "chalangening" deployment environment it makes sense to start with in band first and build on success. I can also point out that this is at the heart of the DNS v HTTPS wars on lookup transport we will resume eventually. From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 28, 2013 1:51 PM To: DOLLY, MARTIN C Cc: stir@ietf.org; Henning Schulzrinne; Dave Crocker; Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band Could you perhaps elaborate? -Ekr On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C > wrote: No retrofits in legacy networks Martin Dolly AT&T Sent from my iPhone On Jun 28, 2013, at 1:23 PM, "Richard Shockey" > wrote: This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren't going to be protected. Why is that true? A huge fraction of circuit switched devices are now smartphones, which could absolutely make use of such a mechanism. In fact, that's precisely the environment for which the system in question was designed. [RS> ] Frankly I would doubt that. I would imagine the mobile operators and Apple would object to anything that creates more signaling over the air. Battery life. Its already an issue in VoLTE deployments. I have trouble imagining any E2E scenarios in a first phase deployment and Penn is absolutely correct that there are not going to be any major retrofits of the legacy networks, certainly not in North America. If the BOF is going to turn on in vs out of band vs both, historically we tend to note that the IETF works best when it builds on some success with one first. -Ekr Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don't see it happening without major refits to the legacy network. So, I'd prefer to concentrate on getting things right in the new world, even if that world isn't coming as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto: stir-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org ] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org ; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF to do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just been to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ 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_00C2_01CE740D.FEB31870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

It is perfectly clear to those of us that have some intimate = knowledge of North American carrier networks that neither the Incumbent = LEC’s , CLEC’s nor the existing mobile operators will not = make any new, much less incremental investments in  TDM = infrastructures.  Go try and get some parts for a DMS 500 or 5ESS = switch these days.

 

All of it is gradually moving to SIP/IMS architectures.  Cable, = with some exceptions, has never relied on TDM in the core.  There = is some chance of implementation at the Gateways where SIP/TDM meet but = that is another issue.

 

http://www.fiercebroadbandwireless.com/story= /t-wants-fccs-blessing-shut-down-pstn/2010-01-03 =

 

That said there is a staggering amount of SIP, SIP Interconnection = AND  DNS/ENUM btw in all NA carrier networks especially those that = support SIP Trunking in the enterprise.  Existing VZ  FIOS and = ATT uVerse  networks use SIP/IMS in the core but the legacy = handsets in the home are treated as B2BUA. Europe is somewhat behind but = there are similar trends there.

 

FCC Form 477 data now indicates that about 1/3 of all US Voice is = SIP/IMS based but not fully SIP/IMS interconnected. Most of it is = converted to TDM for interconnection for a lot of regulatory reasons I = won’t bore you with.  (Section 251 of Act) =

 

All of the existing mobile CDMA/GSM networks still rely on TDM = switches for the Voice service. That is going to change in 18-48 months = as IMS based VoLTE rolls out so a handset tablet solution MAY be = possible then.   Those existing C5 switches in the mobile = networks will be phased out within 5 years or so since the mobile = operators want to refarm the existing spectrum to LTE. In fact your = scenario won’t work on the any existing Version or Sprint networks = since CDMA does not allow for WIFI access and voice at the same = time.  Sorry

 

Marty and Penn are right. The point Hadriel and I have been trying to = make is the STIR solution(s) selected actually have to confront the = reality of what can and will deploy given carrier capital budgets and = overall long term strategy.  The argument is that if out of band = will have a “chalangening” deployment environment it makes = sense to start with in band first and build on success. =

 

I can also point out that this is at the heart of the DNS v HTTPS = wars on lookup transport we will resume = eventually.

 

 

 

 

 

From: = stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Friday, June 28, 2013 1:51 = PM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Henning = Schulzrinne; Dave Crocker; Richard Shockey
Subject: Re: [stir] = Out-of-band vs. in-band

 

Could = you perhaps elaborate?

 

-Ekr

 

 

On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C = <md3135@att.com> = wrote:

No retrofits in legacy = networks

 

Martin Dolly

AT&T 

 

Sent = from my iPhone


On Jun 28, 2013, at = 1:23 PM, "Richard Shockey" <richard@shockey.us> = wrote:

 

 <= /o:p>

 <= /o:p>

This is not going to be generally true until the circuit switched = network is mostly retired; customers hanging off a circuit switch = aren’t going to be = protected.

 <= /o:p>

Why is that = true? A huge fraction of circuit switched devices are now = smartphones,

which could = absolutely make use of such a mechanism. In fact, that's = precisely

the = environment for which the system in question was = designed.

 

[RS> ]  Frankly I would doubt that.  I would imagine the = mobile operators and Apple would object to anything that creates more = signaling over the air.  Battery life. Its already an issue in = VoLTE deployments.  I have trouble imagining any E2E scenarios in a = first phase deployment and Penn is absolutely correct that there are not = going to be any major retrofits of the legacy networks, certainly not in = North America.

 

If the BOF is going to turn on in vs out of band vs both, = historically we tend to note that the IETF works best when it builds on = some success with one first.

 

 

 

-Ekr

 <= /o:p>

Once we have end to end SIP we can do something = in-band.

People might like to have a rapid solution but I just don’t see = it happening without major refits to the legacy network. So, I’d = prefer to concentrate on getting things right in the new world, even if = that world isn’t coming as soon as any of us would = like.

 

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-49= 62

From:= = stir-bounces= @ietf.org = [mailto:stir-bounces= @ietf.org] On = Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 = AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel = Kaplan; stir@ietf.or= g; Dave = Crocker; Brian Rosen; Henning = Schulzrinne


Subje= ct: Re: [stir] Out-of-band vs. = in-band

 <= /o:p>

[Semi-random= ly picking a message to reply to...]

 <= /o:p>

First, let = me say that I'm not at all wedded to anything in the = proposal

that bears = my name and that I presented at the original STIR = meeting.

That = proposal was designed to match a specific set of needs = and

if those = needs aren't needed, then so much the = better.

 <= /o:p>

With that = said, my impression going into that meeting and from = the

discussion = so far was that in fact for the foreseeable future we = are

going to = have environments where:

 <= /o:p>

(1) We want = to have secure caller-id

(2) We = basically can't put anything meaningful in the messages = that

go from = caller to callee (I hasten to add that I don't know = anywhere

near enough = about SS7 to know if that's true, but that was = my

impression).=

 <= /o:p>

If that's = true, then it seems like we really should be considering = some

non-inband = solution from the get-go.

 <= /o:p>

So, for the = people who favor not doing a non-inband solution, do = you

think that = one of the two claims above is untrue? Or do you just = don't

think it = follows that we should be doing something about = it?

 <= /o:p>

Thanks,=

-Ekr

 <= /o:p>

 <= /p>

On Wed, Jun = 26, 2013 at 8:33 AM, Richard Shockey <richard@shockey.us> wrote:

+1 as well = ... take it out of the charter.


-----Ori= ginal Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of

Wendt, = Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <dcrocker@bbiw.net>

Cc: stir@ietf.org; Brian = Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] = Out-of-band vs. in-band

+1

On= Jun 25, 2013, at 1:00 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>> If = that's truly the case - that we plan to do an in-band first, and = when
that's done then an out-of-band one - then I propose we remove = the
out-of-band from the charter.  We can always re-charter and = add new
deliverables when we're ready for an out-of-band mechanism; = we re-charter
all the time in RAI groups.  We might even decide = by then that an
out-of-band mechanism should work very differently, = or that defining one
isn't necessary, or that we don't have the right = participants in the IETF to
do so = successfully.
>>
>> For now, by removing it from the = charter, we can focus on one solution
and not have to debate about = this aspect during the BOF nor WG meetings.  I
am very worried = that we won't have a successful BOF - where I = measure
"success" as reaching consensus to create a Working = Group.  Lengthy
microphone debates kill BOFs, in my experience. = (and I recognize you and
Russ and others have seen far more BOFs than = I have, so maybe I've just been
to the wrong ones = ;)
>
>
> +1.
>
> Narrow, clear = focus.
>
> Good.
>
> 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

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

 <= /o:p>

 <= /o:p>

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

 

------=_NextPart_000_00C2_01CE740D.FEB31870-- From jon.peterson@neustar.biz Fri Jun 28 12:14: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 3549421F855F for ; Fri, 28 Jun 2013 12:14:35 -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_57=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 OvEAjM5+TiU0 for ; Fri, 28 Jun 2013 12:14:31 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDE21F8643 for ; Fri, 28 Jun 2013 12:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372446769; x=1687805363; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=KQBfHK8KsF rAQwHmHFPcK6x+TLa5p+E1fRP0kANIZso=; b=AfV9MZF1cVvAurtllORquo9TH7 Ve+fsInUtNFu4nrJPSO/qyOAqJXPpHYWguE5VKTLdD14c3gDSC6L6LE5ZiTQ== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21565880; Fri, 28 Jun 2013 15:12:47 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 15:13:26 -0400 From: "Peterson, Jon" To: Michael Hammer , "hadriel.kaplan@oracle.com" , "fluffy@cisco.com" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOA Date: Fri, 28 Jun 2013 19:13:26 +0000 Message-ID: In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0EFC1@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4geWZlXFbAPl5pCSFmIldQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <76E7B40B4B56F74995AACC8624CBE517@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 19:14:35 -0000 Extensibility is one way to address it, but if we said "the scope of protection should be configurable as new extensions come along," it would make me share the fears about shades-of-gray that Hadriel has previously expressed. I would much rather be explicit up front about what we think the total scope of protection can be, and what existing deployments will permit. The argument that basing STIR on obsoleting RFC4474 adds new features beyond the motivating requirements is powerful rhetoric, but divorced I think from the actual reality of the IETF work before us. The fact is, we have a body of prior work on authentication services and verification services, on how to create, sign and validate digest-strings, and how to determine signing authorities. I don't think I've heard anyone here (yet, anyway) proposing an alternative architecture, just a change to the digest-string and an addition to the types of signing authority. The changes we need to make in STIR to the digest-string are, with one exception, changes we would make regardless of whether or not the From header field value contained a telephone number. They are changes that will make this work with existing deployments. The one exception is the canonicalization algorithm for telephone numbers we've discussed on the list: that work is specific to telephone numbers. If we're fixing the rest of the digest-string for the TN case, though, we should also fix it for the greenfield case. The greenfield case doesn=B9t introduce any new requirements for this, say. It would not save us any work to treat this as a separate effort from obsoleting the digest-string of RFC4474. The addition of a new category of signing authority for telephone numbers isn't even a wire protocol change, as I've previously pointed out. Identity-Info is already quite flexible in terms of what URI types it supports (including potentially dns URIs). The new work that needs to be done here is on how we compare the (canonicalized) From telephone number with the authority of the signer. But even the logic that inspects the >From field to determine if it contains a telephone number needs to be cognizant of the existence of greenfield identifiers, and trying to cast this such that it operates in complete isolation from the world of greenfield SIP URIs will not be conducive to a robust solution. I have a hard time seeing an argument that it would be better to deploy verification services that can only understand telephone numbers, given the enormous overlap in functionality with understanding native SIP URIs, and the fact that the standardization work on that is already done. There is no new "feature" we'd need to figure out to support greenfield IDs. So again, I don't really see the argument that there's some kind of new work or additional consideration required to take on obsoleting RFC4474. We would be adding some new logic, some different branches to walk down, and fixing some stuff that was previously broken. Yes, we need to agree on what the changes to the digest-string would be, and deciding how body security fits into that (or not) is a place where we could potentially get into the weeds - but whether we're talking about TNs in isolation or along with greenfield identifiers, that discussion isn't going to just go away, we need to have it. That much said, I feel pretty confident we could arrive at a compromise solution that would not burden existing deployments with unnecessary false negatives or needless operations. Jon Peterson Neustar, Inc. On 6/28/13 11:32 AM, "Michael Hammer" wrote: >Perhaps the charter should have a requirement for extensibility. > >Then perhaps those other things can be added in later??? > >Mike > > >-----Original Message----- >From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of >Hadriel Kaplan >Sent: Friday, June 28, 2013 11:21 AM >To: Cullen Jennings (fluffy) >Cc: stir@ietf.org; Jon Peterson >Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR) > > >On Jun 28, 2013, at 11:45 AM, "Cullen Jennings (fluffy)" > >wrote: > >> Just want to be clear we are trying to protect the caller-id for the >>call. >(i'd like to bold the "for the call" part of previous sentence). >>=20 > >No, we're not - or rather, that's not been the problem we've been asked to >solve, and not a problem that's actually occurring. > >We've been asked to solve the problem of bogus+spoofed caller-id's for >*call-initiating requests*. We have not been asked to solve a problem of >valid call requests with bogus media, we have not been asked to solve a >problem of valid calls being hijacked, we have not been asked to solve a >problem of valid calls being eavesdropped, we have not been asked to >solve a >problem of valid calls being routed to the wrong participants, etc. > >We've been asked to solve a real-world problem. We've been told to solve >it >as quickly as possible. We've also essentially been told it needs to be >deployable by carriers, in such a way that they will *want* to deploy it, >because there's not going to be a legal mandate rubber-stamping an IETF >RFC >and forcing the carriers to comply. (There may be such a mandate in some >countries someday, but not the one I live in anyway... not in a short >timeframe) > >I know we'd like to solve a lot of other problems at the same time, >because >it's nice to kill two birds with one stone. But right now other birds >don't >exist, and we have to throw the stone quickly before the single bird gets >away. And a bird in the hand is worth two in the bush. >[heh, two proverbs linked together, cute eh? :) ] > >-hadriel > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Fri Jun 28 12:37: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 6727A21F949F for ; Fri, 28 Jun 2013 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_57=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 X6Mo8L5z1UFx for ; Fri, 28 Jun 2013 12:37:09 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1B21F9A75 for ; Fri, 28 Jun 2013 12:37:05 -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 r5SJUinp025533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 19:30:45 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 r5SJb3CI013195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 19:37:03 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5SJb227008004; Fri, 28 Jun 2013 19:37:02 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 12:37:02 -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, 28 Jun 2013 15:37:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44ACB6D9-BAAC-42E0-BF10-E2D7E6DB7660@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 19:37:14 -0000 If that's all true, then it should be a simple matter to decide to = replace 4474 with the thing we produce, when we either choose an I-D to = be a WG draft, or move closer to publishing a WG draft. I don't believe = not having "we will replace 4474" in the charter would prevent us from = replacing it in the end if we decide our output should replace it. I = don't even think it requires a recharter, does it? So then what are we arguing about? -hadriel On Jun 28, 2013, at 3:13 PM, "Peterson, Jon" = wrote: >=20 > Extensibility is one way to address it, but if we said "the scope of > protection should be configurable as new extensions come along," it = would > make me share the fears about shades-of-gray that Hadriel has = previously > expressed. I would much rather be explicit up front about what we = think > the total scope of protection can be, and what existing deployments = will > permit. >=20 > The argument that basing STIR on obsoleting RFC4474 adds new features > beyond the motivating requirements is powerful rhetoric, but divorced = I > think from the actual reality of the IETF work before us. The fact is, = we > have a body of prior work on authentication services and verification > services, on how to create, sign and validate digest-strings, and how = to > determine signing authorities. I don't think I've heard anyone here = (yet, > anyway) proposing an alternative architecture, just a change to the > digest-string and an addition to the types of signing authority. >=20 > The changes we need to make in STIR to the digest-string are, with one > exception, changes we would make regardless of whether or not the From > header field value contained a telephone number. They are changes that > will make this work with existing deployments. The one exception is = the > canonicalization algorithm for telephone numbers we've discussed on = the > list: that work is specific to telephone numbers. If we're fixing the = rest > of the digest-string for the TN case, though, we should also fix it = for > the greenfield case. The greenfield case doesn=B9t introduce any new > requirements for this, say. It would not save us any work to treat = this as > a separate effort from obsoleting the digest-string of RFC4474. >=20 > The addition of a new category of signing authority for telephone = numbers > isn't even a wire protocol change, as I've previously pointed out. > Identity-Info is already quite flexible in terms of what URI types it > supports (including potentially dns URIs). The new work that needs to = be > done here is on how we compare the (canonicalized) =46rom telephone = number > with the authority of the signer. But even the logic that inspects the > =46rom field to determine if it contains a telephone number needs to = be > cognizant of the existence of greenfield identifiers, and trying to = cast > this such that it operates in complete isolation from the world of > greenfield SIP URIs will not be conducive to a robust solution. I have = a > hard time seeing an argument that it would be better to deploy > verification services that can only understand telephone numbers, = given > the enormous overlap in functionality with understanding native SIP = URIs, > and the fact that the standardization work on that is already done. = There > is no new "feature" we'd need to figure out to support greenfield IDs. >=20 > So again, I don't really see the argument that there's some kind of = new > work or additional consideration required to take on obsoleting = RFC4474. > We would be adding some new logic, some different branches to walk = down, > and fixing some stuff that was previously broken. Yes, we need to = agree on > what the changes to the digest-string would be, and deciding how body > security fits into that (or not) is a place where we could potentially = get > into the weeds - but whether we're talking about TNs in isolation or = along > with greenfield identifiers, that discussion isn't going to just go = away, > we need to have it. That much said, I feel pretty confident we could > arrive at a compromise solution that would not burden existing = deployments > with unnecessary false negatives or needless operations. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 6/28/13 11:32 AM, "Michael Hammer" = wrote: >=20 >> Perhaps the charter should have a requirement for extensibility. >>=20 >> Then perhaps those other things can be added in later??? >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of >> Hadriel Kaplan >> Sent: Friday, June 28, 2013 11:21 AM >> To: Cullen Jennings (fluffy) >> Cc: stir@ietf.org; Jon Peterson >> Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for = STIR) >>=20 >>=20 >> On Jun 28, 2013, at 11:45 AM, "Cullen Jennings (fluffy)" >> >> wrote: >>=20 >>> Just want to be clear we are trying to protect the caller-id for the >>> call. >> (i'd like to bold the "for the call" part of previous sentence). >>>=20 >>=20 >> No, we're not - or rather, that's not been the problem we've been = asked to >> solve, and not a problem that's actually occurring. >>=20 >> We've been asked to solve the problem of bogus+spoofed caller-id's = for >> *call-initiating requests*. We have not been asked to solve a = problem of >> valid call requests with bogus media, we have not been asked to solve = a >> problem of valid calls being hijacked, we have not been asked to = solve a >> problem of valid calls being eavesdropped, we have not been asked to >> solve a >> problem of valid calls being routed to the wrong participants, etc. >>=20 >> We've been asked to solve a real-world problem. We've been told to = solve >> it >> as quickly as possible. We've also essentially been told it needs to = be >> deployable by carriers, in such a way that they will *want* to deploy = it, >> because there's not going to be a legal mandate rubber-stamping an = IETF >> RFC >> and forcing the carriers to comply. (There may be such a mandate in = some >> countries someday, but not the one I live in anyway... not in a short >> timeframe) >>=20 >> I know we'd like to solve a lot of other problems at the same time, >> because >> it's nice to kill two birds with one stone. But right now other = birds >> don't >> exist, and we have to throw the stone quickly before the single bird = gets >> away. And a bird in the hand is worth two in the bush. >> [heh, two proverbs linked together, cute eh? :) ] >>=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 hadriel.kaplan@oracle.com Fri Jun 28 12:56: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 99CEE21F9BCF for ; Fri, 28 Jun 2013 12:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 bR3r1Fgwoxfp for ; Fri, 28 Jun 2013 12:56:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 178C821F9BB1 for ; Fri, 28 Jun 2013 12:56:31 -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 r5SJuOww009925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 19:56:27 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 r5SJuOMT002179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 19:56:24 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 r5SJuOlX002174; Fri, 28 Jun 2013 19:56:24 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 12:56:23 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 28 Jun 2013 15:56:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE2F536-20B6-4DF0-B100-C44F8DCA267B@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 19:56:38 -0000 [breaking this response into two parts - it be gettin' too long] On Jun 27, 2013, at 8:03 PM, "Peterson, Jon" = wrote: > I think there are already a set of discernible and different security > properties of a SIP session. For example, you raise one below, whether = the > media uses SRTP or not. If a call uses identity, we could say it is > somewhat secure, and if it also uses SRTP, we could say its > somewhat-more-secure. You seem to be arguing that if there are two > distinct security properties, the question of how to render them in = the UI > trumps any inherent usefulness in their deployment? Is SRTP only = useful if > a UI is telling you it's there? No, but while "SRTP" isn't useful for a UI, it *is* useful for a = machine/system to use. For users, SRTP isn't useful to know whether = media is secure end-to-end at all, because it should never be assumed to = be end-to-end. It's practical utility today is in securing the specific = network path/hops between its two SRTP-ends, which are far shorter than = end-end; that basically means its practical benefit is limited to = preventing eavesdropping on things like wifi and other insecure hops. So for machines, SRTP can be useful in a black/white way because the = machines can actually be set to only use SRTP and reject calls which = don't use SRTP in specific deployment cases, because there are = deployment scenarios where that makes sense - ones where the admin = believes the network to be insecure from eavesdropping, knows the other = party/parties do as well, and that they should all be using SRTP or the = call must fail. The difference between that, and rfc4474-style signing SDP to verify = it's unchanged all the way from the originating domain, is that I don't = understand what system or user could use it in a black/white way. It's = not needed for scenarios where you know the topology - you would want to = get calls from any originating domain, and yet not trust the carriers in = the middle. But if you're the type of entity who doesn't trust the = carriers in the middle not to mess with your actual media, then you = wouldn't accept any call to begin with from carriers. Signing the SDP = does not prevent the originating carrier or any E.164 delegate/assignee = along the authority-chain from doing whatever they want with the media. = And it doesn't prevent the carriers in the middle from learning a hell = of a lot about your call simply from the signaling. Paranoid entities = simply shouldn't trust such models to be sufficiently secure no matter = what we do. So I'm asking what the scenario is we'd use this info for in a = black/white way - to make some yes/no decision. If we can't show = something different to the users in a UI, and if the system admins can't = do something different with the info, what good is it in practice? I'm not claiming there is no such scenario - I really just don't know = what it would be. I'd like to know it would be useful for something; = otherwise I fear it's a waste of time and counter-productive. > Certainly there are times you might want to be sure SRTP is in place, = and > in those times users should have a way to check it. Similarly, there = might > be times you really want to make sure that the number calling you is > unspoofed, and if the surety isn't there, you may change your = behavior. I'm confused by that statement - are you saying if we don't sign SDP we = can't be sure the number calling us is unspoofed? Obviously we can't = know the audio/video *media* is unspoofed, but we should know the = caller-id number isn't. (or maybe I misunderstand what you mean above?) And no, I'm not an idiot - I do realize most people expect the media to = be from the number calling them. :) But it's simply not possible to provide them such assurance today, and = that hasn't been a real-world problem needing to be solved. We don't = see calls with legitimate caller-id's and spoofed media, and we don't = even see spoofed media in general. And if/when it does happen, the STIR = mechanism won't help us counteract it, because such calls would be = indistinguishable from the 99.999% other calls that have munged SDP. = (ie, all calls would be blocked if we started blocking calls with = changed SDP) -hadriel From hadriel.kaplan@oracle.com Fri Jun 28 12:57: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 48BAE21F9BB1 for ; Fri, 28 Jun 2013 12:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 h2kvvlBCb04l for ; Fri, 28 Jun 2013 12:57:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB921F9BD5 for ; Fri, 28 Jun 2013 12:57:06 -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 r5SJv1oK010411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 19:57:02 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 r5SJv0ur023479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 19:57:01 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 r5SJv0qZ003200; Fri, 28 Jun 2013 19:57:00 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 12:57:00 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 28 Jun 2013 15:56:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38870E27-BBCA-41E1-ABFF-B94647D7097D@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 19:57:12 -0000 [part 2] On Jun 27, 2013, at 8:03 PM, "Peterson, Jon" = wrote: >=20 > But more materially, I am proposing that we create an optional hook = for > the deployments and scenarios where protecting some elements of bodies > makes sense. I fully understand that there are deployments where it = will > not be practical, and I think we can make the hook quite unobtrusive = for > those deployments. Actually it's not unobtrusive. It reveals that carriers in the middle = changed the SDP. > My question to you is, are you so dedicated to the > architecture of SIP request bodies being unprotected that you're = unwilling > to have even an option for this? Hah! I'm "dedicated to the architecture of SIP request bodies being = unprotected"?!? Yes I've dedicated my life to leaving SIP request = bodies unprotected. The Flying Spaghetti Monster himself came down and = told me to never protect SIP bodies. "For the FSM so hated the SIP request bodies, that whoever believes = in Him shall smite the evil bodies at all cost. For they are wicked = bodies=20 full of IP Addresses, and port numbers, and other vile attributes."=20= - Kaplan 3:42 I don't know what I was possibly thinking when I wrote a draft that = allows for signing the SDP or relevant parts thereof: http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity Clearly I had a temporary crisis of faith at the the time. ;) > I'm not sure why you're linking replay protection and body protection = here > - I didn't suggest they were connected in my mail. Replay protection = is > really a question of what headers are going to get signed. As I sent = in a > mail very early in the list, I didn't think from what I read in your = draft > that we're hugely far apart on this. Sorry for the confusion - I thought you were saying we needed to sign = bodies to prevent certain forms of cut-paste attacks. Obviously pure = "replay" attacks can be prevented regardless of SDP. I meant more = cut-paste attacks, as in the baiting-attack, which is a problem I do = worry about with even just caller-id reputability. -hadriel From jon.peterson@neustar.biz Fri Jun 28 13:03: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 09D8321F9C2A for ; Fri, 28 Jun 2013 13:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.123 X-Spam-Level: X-Spam-Status: No, score=-105.123 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MIME_BASE64_TEXT=1.753, 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 M6dLa76F5JVZ for ; Fri, 28 Jun 2013 13:03:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C834A21F9A65 for ; Fri, 28 Jun 2013 13:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372450323; x=1687804391; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=4rlHPaPrkl RzjsXUhWYqdzg4BHLmxA/oKpT1ISpN0mE=; b=szJ99mFMzhQ+j0y4tr/KfuLq1+ C5f4/FOg6NaKitRrP0avOTY9utptJZlmwXoWIRHBOMnSRo+NqXH3SrdUdJHw== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27042044; Fri, 28 Jun 2013 16:12:02 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 16:03:40 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOAgAB77wD//5IYgA== Date: Fri, 28 Jun 2013 20:03:40 +0000 Message-ID: In-Reply-To: <44ACB6D9-BAAC-42E0-BF10-E2D7E6DB7660@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 56Ms+hQMi7wOYF4HLdaCsg== Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 20:03:49 -0000 DQpJIGtub3csIHJpZ2h0PyENCg0KQnV0IHNlcmlvdXNseSwgdGhlcmUncyBhIGxvdCBvZiAiaWZz IiBpbiB5b3VyIHN0YXRlbWVudCBiZWxvdy4gSSdtDQpjb25jZXJuZWQgdGhhdCBpZiB3ZSBzdGFy dCBvdXQgd2l0aCBhIG5vbi1nb2FsIG9mIHJlcGxhY2luZyBSRkM0NDc0LCB3ZQ0KY291bGQgZHVw bGljYXRlIGEgbG90IG9mIGRlc2lnbiBhbmQgZWZmb3J0IGFuZCBhcmNoaXRlY3R1cmUgKGFuZCBw cmV0dHkNCm11Y2ggdGV4dCwgZXZlbikgYW5kIHlldCwgaW4gdGhlIG5hbWUgb2YgcGFyc2ltb25p b3VzbmVzcywgZW5kIHVwIHdpdGggdHdvDQpkaWZmZXJlbnQgZmxhdm9ycyBvZiB2ZXJpZmljYXRp b24gYW5kIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2VzIHRoYXQgYXMNCnNwZWNpZmljYXRpb25zIG5l ZWQgdG8gYmUgc2VwYXJhdGVseSB1cGRhdGVkIGFuZCBrZXB0IGluIHN5bmNoIGFuZCBzbyBvbi4N CkknZCByYXRoZXIgbmlwIHRoYXQgYXQgdGhlIGJ1ZC4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFy LCBJbmMNCg0KT24gNi8yOC8xMyAxMjozNyBQTSwgIkhhZHJpZWwgS2FwbGFuIiA8aGFkcmllbC5r YXBsYW5Ab3JhY2xlLmNvbT4gd3JvdGU6DQoNCj4NCj5JZiB0aGF0J3MgYWxsIHRydWUsIHRoZW4g aXQgc2hvdWxkIGJlIGEgc2ltcGxlIG1hdHRlciB0byBkZWNpZGUgdG8NCj5yZXBsYWNlIDQ0NzQg d2l0aCB0aGUgdGhpbmcgd2UgcHJvZHVjZSwgd2hlbiB3ZSBlaXRoZXIgY2hvb3NlIGFuIEktRCB0 bw0KPmJlIGEgV0cgZHJhZnQsIG9yIG1vdmUgY2xvc2VyIHRvIHB1Ymxpc2hpbmcgYSBXRyBkcmFm dC4gIEkgZG9uJ3QgYmVsaWV2ZQ0KPm5vdCBoYXZpbmcgIndlIHdpbGwgcmVwbGFjZSA0NDc0IiBp biB0aGUgY2hhcnRlciB3b3VsZCBwcmV2ZW50IHVzIGZyb20NCj5yZXBsYWNpbmcgaXQgaW4gdGhl IGVuZCBpZiB3ZSBkZWNpZGUgb3VyIG91dHB1dCBzaG91bGQgcmVwbGFjZSBpdC4gIEkNCj5kb24n dCBldmVuIHRoaW5rIGl0IHJlcXVpcmVzIGEgcmVjaGFydGVyLCBkb2VzIGl0Pw0KPg0KPlNvIHRo ZW4gd2hhdCBhcmUgd2UgYXJndWluZyBhYm91dD8NCj4NCj4taGFkcmllbA0KPg0KPg0KPk9uIEp1 biAyOCwgMjAxMywgYXQgMzoxMyBQTSwgIlBldGVyc29uLCBKb24iIDxqb24ucGV0ZXJzb25AbmV1 c3Rhci5iaXo+DQo+d3JvdGU6DQo+DQo+PiANCj4+IEV4dGVuc2liaWxpdHkgaXMgb25lIHdheSB0 byBhZGRyZXNzIGl0LCBidXQgaWYgd2Ugc2FpZCAidGhlIHNjb3BlIG9mDQo+PiBwcm90ZWN0aW9u IHNob3VsZCBiZSBjb25maWd1cmFibGUgYXMgbmV3IGV4dGVuc2lvbnMgY29tZSBhbG9uZywiIGl0 DQo+PndvdWxkDQo+PiBtYWtlIG1lIHNoYXJlIHRoZSBmZWFycyBhYm91dCBzaGFkZXMtb2YtZ3Jh eSB0aGF0IEhhZHJpZWwgaGFzIHByZXZpb3VzbHkNCj4+IGV4cHJlc3NlZC4gSSB3b3VsZCBtdWNo IHJhdGhlciBiZSBleHBsaWNpdCB1cCBmcm9udCBhYm91dCB3aGF0IHdlIHRoaW5rDQo+PiB0aGUg dG90YWwgc2NvcGUgb2YgcHJvdGVjdGlvbiBjYW4gYmUsIGFuZCB3aGF0IGV4aXN0aW5nIGRlcGxv eW1lbnRzIHdpbGwNCj4+IHBlcm1pdC4NCj4+IA0KPj4gVGhlIGFyZ3VtZW50IHRoYXQgYmFzaW5n IFNUSVIgb24gb2Jzb2xldGluZyBSRkM0NDc0IGFkZHMgbmV3IGZlYXR1cmVzDQo+PiBiZXlvbmQg dGhlIG1vdGl2YXRpbmcgcmVxdWlyZW1lbnRzIGlzIHBvd2VyZnVsIHJoZXRvcmljLCBidXQgZGl2 b3JjZWQgSQ0KPj4gdGhpbmsgZnJvbSB0aGUgYWN0dWFsIHJlYWxpdHkgb2YgdGhlIElFVEYgd29y ayBiZWZvcmUgdXMuIFRoZSBmYWN0IGlzLA0KPj53ZQ0KPj4gaGF2ZSBhIGJvZHkgb2YgcHJpb3Ig d29yayBvbiBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlcyBhbmQgdmVyaWZpY2F0aW9uDQo+PiBzZXJ2 aWNlcywgb24gaG93IHRvIGNyZWF0ZSwgc2lnbiBhbmQgdmFsaWRhdGUgZGlnZXN0LXN0cmluZ3Ms IGFuZCBob3cgdG8NCj4+IGRldGVybWluZSBzaWduaW5nIGF1dGhvcml0aWVzLiBJIGRvbid0IHRo aW5rIEkndmUgaGVhcmQgYW55b25lIGhlcmUNCj4+KHlldCwNCj4+IGFueXdheSkgcHJvcG9zaW5n IGFuIGFsdGVybmF0aXZlIGFyY2hpdGVjdHVyZSwganVzdCBhIGNoYW5nZSB0byB0aGUNCj4+IGRp Z2VzdC1zdHJpbmcgYW5kIGFuIGFkZGl0aW9uIHRvIHRoZSB0eXBlcyBvZiBzaWduaW5nIGF1dGhv cml0eS4NCj4+IA0KPj4gVGhlIGNoYW5nZXMgd2UgbmVlZCB0byBtYWtlIGluIFNUSVIgdG8gdGhl IGRpZ2VzdC1zdHJpbmcgYXJlLCB3aXRoIG9uZQ0KPj4gZXhjZXB0aW9uLCBjaGFuZ2VzIHdlIHdv dWxkIG1ha2UgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgRnJvbQ0KPj4gaGVhZGVy IGZpZWxkIHZhbHVlIGNvbnRhaW5lZCBhIHRlbGVwaG9uZSBudW1iZXIuIFRoZXkgYXJlIGNoYW5n ZXMgdGhhdA0KPj4gd2lsbCBtYWtlIHRoaXMgd29yayB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRz LiBUaGUgb25lIGV4Y2VwdGlvbiBpcyB0aGUNCj4+IGNhbm9uaWNhbGl6YXRpb24gYWxnb3JpdGht IGZvciB0ZWxlcGhvbmUgbnVtYmVycyB3ZSd2ZSBkaXNjdXNzZWQgb24gdGhlDQo+PiBsaXN0OiB0 aGF0IHdvcmsgaXMgc3BlY2lmaWMgdG8gdGVsZXBob25lIG51bWJlcnMuIElmIHdlJ3JlIGZpeGlu ZyB0aGUNCj4+cmVzdA0KPj4gb2YgdGhlIGRpZ2VzdC1zdHJpbmcgZm9yIHRoZSBUTiBjYXNlLCB0 aG91Z2gsIHdlIHNob3VsZCBhbHNvIGZpeCBpdCBmb3INCj4+IHRoZSBncmVlbmZpZWxkIGNhc2Uu IFRoZSBncmVlbmZpZWxkIGNhc2UgZG9lc26p9nQgaW50cm9kdWNlIGFueSBuZXcNCj4+IHJlcXVp cmVtZW50cyBmb3IgdGhpcywgc2F5LiBJdCB3b3VsZCBub3Qgc2F2ZSB1cyBhbnkgd29yayB0byB0 cmVhdCB0aGlzDQo+PmFzDQo+PiBhIHNlcGFyYXRlIGVmZm9ydCBmcm9tIG9ic29sZXRpbmcgdGhl IGRpZ2VzdC1zdHJpbmcgb2YgUkZDNDQ3NC4NCj4+IA0KPj4gVGhlIGFkZGl0aW9uIG9mIGEgbmV3 IGNhdGVnb3J5IG9mIHNpZ25pbmcgYXV0aG9yaXR5IGZvciB0ZWxlcGhvbmUNCj4+bnVtYmVycw0K Pj4gaXNuJ3QgZXZlbiBhIHdpcmUgcHJvdG9jb2wgY2hhbmdlLCBhcyBJJ3ZlIHByZXZpb3VzbHkg cG9pbnRlZCBvdXQuDQo+PiBJZGVudGl0eS1JbmZvIGlzIGFscmVhZHkgcXVpdGUgZmxleGlibGUg aW4gdGVybXMgb2Ygd2hhdCBVUkkgdHlwZXMgaXQNCj4+IHN1cHBvcnRzIChpbmNsdWRpbmcgcG90 ZW50aWFsbHkgZG5zIFVSSXMpLiBUaGUgbmV3IHdvcmsgdGhhdCBuZWVkcyB0byBiZQ0KPj4gZG9u ZSBoZXJlIGlzIG9uIGhvdyB3ZSBjb21wYXJlIHRoZSAoY2Fub25pY2FsaXplZCkgRnJvbSB0ZWxl cGhvbmUgbnVtYmVyDQo+PiB3aXRoIHRoZSBhdXRob3JpdHkgb2YgdGhlIHNpZ25lci4gQnV0IGV2 ZW4gdGhlIGxvZ2ljIHRoYXQgaW5zcGVjdHMgdGhlDQo+PiBGcm9tIGZpZWxkIHRvIGRldGVybWlu ZSBpZiBpdCBjb250YWlucyBhIHRlbGVwaG9uZSBudW1iZXIgbmVlZHMgdG8gYmUNCj4+IGNvZ25p emFudCBvZiB0aGUgZXhpc3RlbmNlIG9mIGdyZWVuZmllbGQgaWRlbnRpZmllcnMsIGFuZCB0cnlp bmcgdG8gY2FzdA0KPj4gdGhpcyBzdWNoIHRoYXQgaXQgb3BlcmF0ZXMgaW4gY29tcGxldGUgaXNv bGF0aW9uIGZyb20gdGhlIHdvcmxkIG9mDQo+PiBncmVlbmZpZWxkIFNJUCBVUklzIHdpbGwgbm90 IGJlIGNvbmR1Y2l2ZSB0byBhIHJvYnVzdCBzb2x1dGlvbi4gSSBoYXZlIGENCj4+IGhhcmQgdGlt ZSBzZWVpbmcgYW4gYXJndW1lbnQgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVwbG95DQo+ PiB2ZXJpZmljYXRpb24gc2VydmljZXMgdGhhdCBjYW4gb25seSB1bmRlcnN0YW5kIHRlbGVwaG9u ZSBudW1iZXJzLCBnaXZlbg0KPj4gdGhlIGVub3Jtb3VzIG92ZXJsYXAgaW4gZnVuY3Rpb25hbGl0 eSB3aXRoIHVuZGVyc3RhbmRpbmcgbmF0aXZlIFNJUA0KPj5VUklzLA0KPj4gYW5kIHRoZSBmYWN0 IHRoYXQgdGhlIHN0YW5kYXJkaXphdGlvbiB3b3JrIG9uIHRoYXQgaXMgYWxyZWFkeSBkb25lLg0K Pj5UaGVyZQ0KPj4gaXMgbm8gbmV3ICJmZWF0dXJlIiB3ZSdkIG5lZWQgdG8gZmlndXJlIG91dCB0 byBzdXBwb3J0IGdyZWVuZmllbGQgSURzLg0KPj4gDQo+PiBTbyBhZ2FpbiwgSSBkb24ndCByZWFs bHkgc2VlIHRoZSBhcmd1bWVudCB0aGF0IHRoZXJlJ3Mgc29tZSBraW5kIG9mIG5ldw0KPj4gd29y ayBvciBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb24gcmVxdWlyZWQgdG8gdGFrZSBvbiBvYnNvbGV0 aW5nIFJGQzQ0NzQuDQo+PiBXZSB3b3VsZCBiZSBhZGRpbmcgc29tZSBuZXcgbG9naWMsIHNvbWUg ZGlmZmVyZW50IGJyYW5jaGVzIHRvIHdhbGsgZG93biwNCj4+IGFuZCBmaXhpbmcgc29tZSBzdHVm ZiB0aGF0IHdhcyBwcmV2aW91c2x5IGJyb2tlbi4gWWVzLCB3ZSBuZWVkIHRvIGFncmVlDQo+Pm9u DQo+PiB3aGF0IHRoZSBjaGFuZ2VzIHRvIHRoZSBkaWdlc3Qtc3RyaW5nIHdvdWxkIGJlLCBhbmQg ZGVjaWRpbmcgaG93IGJvZHkNCj4+IHNlY3VyaXR5IGZpdHMgaW50byB0aGF0IChvciBub3QpIGlz IGEgcGxhY2Ugd2hlcmUgd2UgY291bGQgcG90ZW50aWFsbHkNCj4+Z2V0DQo+PiBpbnRvIHRoZSB3 ZWVkcyAtIGJ1dCB3aGV0aGVyIHdlJ3JlIHRhbGtpbmcgYWJvdXQgVE5zIGluIGlzb2xhdGlvbiBv cg0KPj5hbG9uZw0KPj4gd2l0aCBncmVlbmZpZWxkIGlkZW50aWZpZXJzLCB0aGF0IGRpc2N1c3Np b24gaXNuJ3QgZ29pbmcgdG8ganVzdCBnbw0KPj5hd2F5LA0KPj4gd2UgbmVlZCB0byBoYXZlIGl0 LiBUaGF0IG11Y2ggc2FpZCwgSSBmZWVsIHByZXR0eSBjb25maWRlbnQgd2UgY291bGQNCj4+IGFy cml2ZSBhdCBhIGNvbXByb21pc2Ugc29sdXRpb24gdGhhdCB3b3VsZCBub3QgYnVyZGVuIGV4aXN0 aW5nDQo+PmRlcGxveW1lbnRzDQo+PiB3aXRoIHVubmVjZXNzYXJ5IGZhbHNlIG5lZ2F0aXZlcyBv ciBuZWVkbGVzcyBvcGVyYXRpb25zLg0KPj4gDQo+PiBKb24gUGV0ZXJzb24NCj4+IE5ldXN0YXIs IEluYy4NCj4+IA0KPj4gT24gNi8yOC8xMyAxMTozMiBBTSwgIk1pY2hhZWwgSGFtbWVyIiA8bWlj aGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbT4NCj4+d3JvdGU6DQo+PiANCj4+PiBQZXJoYXBzIHRo ZSBjaGFydGVyIHNob3VsZCBoYXZlIGEgcmVxdWlyZW1lbnQgZm9yIGV4dGVuc2liaWxpdHkuDQo+ Pj4gDQo+Pj4gVGhlbiBwZXJoYXBzIHRob3NlIG90aGVyIHRoaW5ncyBjYW4gYmUgYWRkZWQgaW4g bGF0ZXI/Pz8NCj4+PiANCj4+PiBNaWtlDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBzdGlyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGly LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4+IEhhZHJpZWwgS2FwbGFuDQo+Pj4g U2VudDogRnJpZGF5LCBKdW5lIDI4LCAyMDEzIDExOjIxIEFNDQo+Pj4gVG86IEN1bGxlbiBKZW5u aW5ncyAoZmx1ZmZ5KQ0KPj4+IENjOiBzdGlyQGlldGYub3JnOyBKb24gUGV0ZXJzb24NCj4+PiBT dWJqZWN0OiBSZTogW3N0aXJdIFJlcGxhY2luZyByZmM0NDc0ICh3YXM6IFJldmlzZWQgY2hhcnRl ciB0ZXh0IGZvcg0KPj4+U1RJUikNCj4+PiANCj4+PiANCj4+PiBPbiBKdW4gMjgsIDIwMTMsIGF0 IDExOjQ1IEFNLCAiQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIg0KPj4+IDxmbHVmZnlAY2lzY28u Y29tPg0KPj4+IHdyb3RlOg0KPj4+IA0KPj4+PiBKdXN0IHdhbnQgdG8gYmUgY2xlYXIgd2UgYXJl IHRyeWluZyB0byBwcm90ZWN0IHRoZSBjYWxsZXItaWQgZm9yIHRoZQ0KPj4+PiBjYWxsLg0KPj4+ IChpJ2QgbGlrZSB0byBib2xkIHRoZSAiZm9yIHRoZSBjYWxsIiBwYXJ0IG9mIHByZXZpb3VzIHNl bnRlbmNlKS4NCj4+Pj4gDQo+Pj4gDQo+Pj4gTm8sIHdlJ3JlIG5vdCAtIG9yIHJhdGhlciwgdGhh dCdzIG5vdCBiZWVuIHRoZSBwcm9ibGVtIHdlJ3ZlIGJlZW4NCj4+PmFza2VkIHRvDQo+Pj4gc29s dmUsIGFuZCBub3QgYSBwcm9ibGVtIHRoYXQncyBhY3R1YWxseSBvY2N1cnJpbmcuDQo+Pj4gDQo+ Pj4gV2UndmUgYmVlbiBhc2tlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBib2d1cytzcG9vZmVk IGNhbGxlci1pZCdzIGZvcg0KPj4+ICpjYWxsLWluaXRpYXRpbmcgcmVxdWVzdHMqLiAgV2UgaGF2 ZSBub3QgYmVlbiBhc2tlZCB0byBzb2x2ZSBhIHByb2JsZW0NCj4+Pm9mDQo+Pj4gdmFsaWQgY2Fs bCByZXF1ZXN0cyB3aXRoIGJvZ3VzIG1lZGlhLCB3ZSBoYXZlIG5vdCBiZWVuIGFza2VkIHRvIHNv bHZlIGENCj4+PiBwcm9ibGVtIG9mIHZhbGlkIGNhbGxzIGJlaW5nIGhpamFja2VkLCB3ZSBoYXZl IG5vdCBiZWVuIGFza2VkIHRvIHNvbHZlDQo+Pj5hDQo+Pj4gcHJvYmxlbSBvZiB2YWxpZCBjYWxs cyBiZWluZyBlYXZlc2Ryb3BwZWQsIHdlIGhhdmUgbm90IGJlZW4gYXNrZWQgdG8NCj4+PiBzb2x2 ZSBhDQo+Pj4gcHJvYmxlbSBvZiB2YWxpZCBjYWxscyBiZWluZyByb3V0ZWQgdG8gdGhlIHdyb25n IHBhcnRpY2lwYW50cywgZXRjLg0KPj4+IA0KPj4+IFdlJ3ZlIGJlZW4gYXNrZWQgdG8gc29sdmUg YSByZWFsLXdvcmxkIHByb2JsZW0uICBXZSd2ZSBiZWVuIHRvbGQgdG8NCj4+PnNvbHZlDQo+Pj4g aXQNCj4+PiBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiAgV2UndmUgYWxzbyBlc3NlbnRpYWxseSBi ZWVuIHRvbGQgaXQgbmVlZHMgdG8NCj4+PmJlDQo+Pj4gZGVwbG95YWJsZSBieSBjYXJyaWVycywg aW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgd2lsbCAqd2FudCogdG8gZGVwbG95DQo+Pj5pdCwNCj4+ PiBiZWNhdXNlIHRoZXJlJ3Mgbm90IGdvaW5nIHRvIGJlIGEgbGVnYWwgbWFuZGF0ZSBydWJiZXIt c3RhbXBpbmcgYW4gSUVURg0KPj4+IFJGQw0KPj4+IGFuZCBmb3JjaW5nIHRoZSBjYXJyaWVycyB0 byBjb21wbHkuIChUaGVyZSBtYXkgYmUgc3VjaCBhIG1hbmRhdGUgaW4NCj4+PnNvbWUNCj4+PiBj b3VudHJpZXMgc29tZWRheSwgYnV0IG5vdCB0aGUgb25lIEkgbGl2ZSBpbiBhbnl3YXkuLi4gbm90 IGluIGEgc2hvcnQNCj4+PiB0aW1lZnJhbWUpDQo+Pj4gDQo+Pj4gSSBrbm93IHdlJ2QgbGlrZSB0 byBzb2x2ZSBhIGxvdCBvZiBvdGhlciBwcm9ibGVtcyBhdCB0aGUgc2FtZSB0aW1lLA0KPj4+IGJl Y2F1c2UNCj4+PiBpdCdzIG5pY2UgdG8ga2lsbCB0d28gYmlyZHMgd2l0aCBvbmUgc3RvbmUuICBC dXQgcmlnaHQgbm93IG90aGVyIGJpcmRzDQo+Pj4gZG9uJ3QNCj4+PiBleGlzdCwgYW5kIHdlIGhh dmUgdG8gdGhyb3cgdGhlIHN0b25lIHF1aWNrbHkgYmVmb3JlIHRoZSBzaW5nbGUgYmlyZA0KPj4+ Z2V0cw0KPj4+IGF3YXkuICBBbmQgYSBiaXJkIGluIHRoZSBoYW5kIGlzIHdvcnRoIHR3byBpbiB0 aGUgYnVzaC4NCj4+PiBbaGVoLCB0d28gcHJvdmVyYnMgbGlua2VkIHRvZ2V0aGVyLCBjdXRlIGVo PyA6KSBdDQo+Pj4gDQo+Pj4gLWhhZHJpZWwNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+Pj4g c3RpckBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3Rpcg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPg0KDQo= From york@isoc.org Fri Jun 28 13:34: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 6792121F99B0 for ; Fri, 28 Jun 2013 13:34:30 -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=[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 RiQTIzOfXac9 for ; Fri, 28 Jun 2013 13:34:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id D351C21F8651 for ; Fri, 28 Jun 2013 13:34:24 -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.702.21; Fri, 28 Jun 2013 20:34:21 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.130]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.15]) with mapi id 15.00.0702.005; Fri, 28 Jun 2013 20:34:21 +0000 From: Dan York To: "Peterson, Jon" , Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qYL+LLrStPTUyYM8Bezww2T5lLRiwAgAArZACAAAM/gIAAC30AgAAGlQCAAAd0AP//xYMA Date: Fri, 28 Jun 2013 20:34:20 +0000 Message-ID: In-Reply-To: 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: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(199002)(479174003)(377454003)(74876001)(77982001)(36756003)(54316002)(76176001)(76482001)(59766001)(63696002)(53806001)(80022001)(76786001)(56816003)(69226001)(56776001)(77096001)(76796001)(51856001)(65816001)(47446002)(50986001)(47736001)(49866001)(4396001)(81542001)(74366001)(74662001)(46102001)(47976001)(83072001)(54356001)(79102001)(74502001)(74706001)(31966008)(81342001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 20:34:30 -0000 On 6/28/13 4:03 PM, "Peterson, Jon" wrote: >I'm concerned that if we start out with a non-goal of replacing RFC4474, >we >could duplicate a lot of design and effort and architecture (and pretty >much text, even) and yet, in the name of parsimoniousness, end up with two >different flavors of verification and authentication services that as >specifications need to be separately updated and kept in synch and so on. >I'd rather nip that at the bud. I hear what you are saying, Jon, but we've heard time and time again in various conversations that RFC4474 is "not being deployed" and is not being used because it has too many challenges in the way SIP systems are deployed today. So it may be more accurate to say that we might end up with: 1. one flavor of verification and authentication services that "nobody uses" (RFC 4474) 2. one flavor of verification and authentication services that is focused on telephone numbers (STIR) And if this is the case I would ask if we really need to worry about #1 at this point in time. Might it not be better to focus on getting a STIR solution out and THEN look at a 4474bis that looks at the larger 4474 challenges and integrates the STIR work into that larger work? My concern with adding a piece to the charter about replacing 4474 means that it becomes yet one more thing that needs to be completed - and we don't know if in fact a STIR solution will truly be able to replace 4474. We might find that the simplest and most easily deployable solution for STIR will not solve all the challenges of 4474 - and yet if the charter says we need to replace 4474 we're then either trying to make it do so or we're rechartering. Let's make the charter as simple and focused as possible. When we get to where we have an agreed-upon solution we can decide if it can, in fact, replace 4474 and can make that decision then. My 2 cents, Dan From hadriel.kaplan@oracle.com Fri Jun 28 13:48: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 71B9321F99B0 for ; Fri, 28 Jun 2013 13:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 36bz1-OXPtA2 for ; Fri, 28 Jun 2013 13:48:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id F036221F8605 for ; Fri, 28 Jun 2013 13:48: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 r5SKg5Xv029833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 20:42:06 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 r5SKmOGr029425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 20:48:24 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 r5SKmNg6011810; Fri, 28 Jun 2013 20:48:23 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jun 2013 13:48:23 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 28 Jun 2013 16:48:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1313DDB0-B92F-409A-82D0-5B96BFD88968@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 20:48:33 -0000 OK, but I'm concerned that if we start out with a goal of replacing = RFC4474, that we're constrained to providing the same level of = protection, for the same information/aspects, against the same type of = attack vectors. I'm *not* concerned we'll have to protect the literal = From/To/Date/Call-ID/Cseq header field values, because I think we can = work around those, but I'm concerned that we'll be required to protect = bodies or even parts thereof. And I *am* expecting to discuss design and architecture, and don't want = to be constrained to even having to support a URL model. Yes one could = put 'dns' in it, but if it would be up to the originator to decide = whether to put 'dns' or 'http' in it, then I think there will be a = discussion to have about that in the WG - and I don't want someone to = just be able to say "we have to have it because it's already in RFC = 4474". And you know people say things like that all the time in WG's, = using the charter as a club to beat down discussion. -hadriel On Jun 28, 2013, at 4:03 PM, "Peterson, Jon" = wrote: >=20 > I know, right?! >=20 > But seriously, there's a lot of "ifs" in your statement below. I'm > concerned that if we start out with a non-goal of replacing RFC4474, = we > could duplicate a lot of design and effort and architecture (and = pretty > much text, even) and yet, in the name of parsimoniousness, end up with = two > different flavors of verification and authentication services that as > specifications need to be separately updated and kept in synch and so = on. > I'd rather nip that at the bud. >=20 > Jon Peterson > Neustar, Inc From jon.peterson@neustar.biz Fri Jun 28 13:59: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 A06DF21F99AF for ; Fri, 28 Jun 2013 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.584 X-Spam-Level: X-Spam-Status: No, score=-105.584 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 DRJF14-2YvRi for ; Fri, 28 Jun 2013 13:59:33 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0938121F9956 for ; Fri, 28 Jun 2013 13:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372453645; x=1687813162; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=P/vQr+fjB4 Uv2Rs6s94SKauiZ+OI5dOPzddwX6x2JvQ=; b=Oa8O8Wk1V5YUAIARcVTu/HjtDy YKAqj3sXy1yJDMOsJPpmKGT440pwroDGo65xTICngoZw44MWwCnOlkN0C01g== Received: from ([10.31.58.71]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.27045205; Fri, 28 Jun 2013 17:07:24 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 16:59:03 -0400 From: "Peterson, Jon" To: "dcrocker@bbiw.net" Thread-Topic: [stir] Revised charter text for STIR Thread-Index: AQHOc0RP7qgb0/rNTkuQHAXjKZBP65lKCYKA//+ayYCAAMtVAP//p7mAgADAxICAAJOxgA== Date: Fri, 28 Jun 2013 20:59:03 +0000 Message-ID: In-Reply-To: <51CD1AC1.5010106@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: UeETyMh86ymdFDe7zo98+g== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 28 Jun 2013 20:59:37 -0000 While I don't entirely agree with the account of numbering administration or assignment offered below, it certainly acknowledges that entities other than end users will sign for telephone identities. The point I raised about the proposed charter text was that I wasn't sure what actors it means where it reads that signing authority rests with "the entity formally assigned use of that number, or their delegate." I don't think there really is any formal assignment, there's a loose and sometimes convoluted process of delegation with many strange corner cases, and many numbers that aren't assigned to users at all. I don't think naming users as the font of authority, who then (implicitly, I guess) delegate to carriers authority to sign for numbers, is at all indicative of the deployment environment or the realities of numbering. It seems to me that, much like public ENUM, this language expresses a wish about how numbering should work; and like public ENUM, it would have to bend the realities of number administration, as infrastructure ENUM does, before a path to adoption became clear. Jon Peterson Neustar, Inc. On 6/27/13 10:10 PM, "Dave Crocker" wrote: >On 6/27/2013 5:40 PM, Peterson, Jon wrote: >>> No doubt, some signers will be telcos or other operators, and this >>>might >>> seem confusing, but they are doing it /on behalf of/ the end user. >>>Even >>> if real end users happen not to know their calls are being protected >>> with a signature on their behalf, it is on their behalf. It's not "by" >>> the operator. They are a delegate of the user. >> >> I think many people on this list would view telcos signing as the >>everyday >> case, and end-user signators as the exception. From an assignment >> perspective, carriers are certainly not (in contemporary North America >> anyway) delegates of the user; users are delegates of the carrier. >> Moreover there are plenty of other actors, like resellers, enterprises, >> etc who are also delegates and potentially signers. The problem again >>with >> the "the entity formally assigned use" language is that it treats the >> concept of "assignee" as if numbers have a single authority, but the >> reason "assignee" is a better term here than "owner" is because it >>doesn't >> have the connotation that there's some single authority. Numbering >>doesn't >> work that way. > > > >End users are not working "on behalf of" the provider. The term >"delegate" would mean they were... So, no, the end user is not a >delegate of the telco. > >It's important not to confuse the mechanics of some actions with the >roles being performed. We need to distinguish among several different >roles and several different actions and a couple of different >legitimization models. > > >Values are administered, possibly through a hierarchy. Ultimately, they >are assigned for 'use'. Look into a reverse white pages and you won't >find reference to the telco or Neustar. You'll find the user who >answers the phone. > >Administrators are not 'users'. Yeah, they mess with the value, but >they are performing support functions. > >Operators also perform some functions that touch the value. Back when >telephone numbers were tied to switch topology, of course, the >relationship was tighter. But again, they are not 'users'. They are >providers. The difference is fundamental. > >We need to avoid confusing support functions -- whether administration >or operations -- from assignment to the end-user. > >The history with telephone numbers has conflated a number of different >roles into the same set of actors. Number portability highlights that >they really are different roles. They further make clear that the >assignment of the number is detached from the telco that assigns it to >the end user. > >Yes, the number can be taken back from the end user, but not at the whim >of the telco. And it's generally not permitted to say 'owner' when a >continued licensing fee is required to retain rights. > > >Lastly is the role of vouching for validity. The end user can vouch for >their own use, because have that authority. But it's plausible that >others might do the vouching, either because the end user delegated that >right to them or because the services that check for validity lend >credence to some other agents. This moves from a simple, objective >assignment-based model for validation to one that looks more like >third-party reputation. > >So a telco doing signing is fine, either because they are doing it with >the user's implicit/explicit permission, or because the assessment >service chooses to treat the telco as a trusted agent. > >d/ > > > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From md3135@att.com Fri Jun 28 14:10: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 369E921F9A5F for ; Fri, 28 Jun 2013 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=2.947, 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 l9JQpxd7D307 for ; Fri, 28 Jun 2013 14:09:59 -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 5EA4C21F85D1 for ; Fri, 28 Jun 2013 14:09:59 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 7abfdc15.75c67940.6400050.00-591.17829444.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 21:09:59 +0000 (UTC) X-MXL-Hash: 51cdfba718116161-78ab837097e8cf9f88af29d386aa356d0c1e895b Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6abfdc15.0.6400047.00-243.17829422.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 21:09:58 +0000 (UTC) X-MXL-Hash: 51cdfba673e738c1-72cc2e4cfbc2143ddd5a3abf1976e7b0cb98951a 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 r5SL9v1l008896; Fri, 28 Jun 2013 17:09:58 -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 r5SL9n3Z008810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 17:09:51 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 21:09:35 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; Fri, 28 Jun 2013 17:09:44 -0400 From: "DOLLY, MARTIN C" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOAgAB77wD//5IYgIAAgdiA///C6rs= Date: Fri, 28 Jun 2013 21:09:43 +0000 Message-ID: <742835C4-3312-4F93-9995-6E54729097C4@att.com> References: , <1313DDB0-B92F-409A-82D0-5B96BFD88968@oracle.com> In-Reply-To: <1313DDB0-B92F-409A-82D0-5B96BFD88968@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 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=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=qvXq6a5bQMYA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=SmorGXxrPMUA:10 a=yPCof4Zb] X-AnalysisOut: [AAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=FMhV6By-YZHmg4l] X-AnalysisOut: [c_McA:9 a=CjuIK1q_8ugA:10 a=7DSvI1NPTFQA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10] Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer , "Peterson, Jon" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 21:10:05 -0000 Being the scope in RFC4474 is broader than this effort, how can this replac= e it Martin Dolly AT&T=20 Sent from my iPhone On Jun 28, 2013, at 4:48 PM, "Hadriel Kaplan" w= rote: >=20 > OK, but I'm concerned that if we start out with a goal of replacing RFC44= 74, that we're constrained to providing the same level of protection, for t= he same information/aspects, against the same type of attack vectors. I'm = *not* concerned we'll have to protect the literal From/To/Date/Call-ID/Cseq= header field values, because I think we can work around those, but I'm con= cerned that we'll be required to protect bodies or even parts thereof. >=20 > And I *am* expecting to discuss design and architecture, and don't want t= o be constrained to even having to support a URL model. Yes one could put = 'dns' in it, but if it would be up to the originator to decide whether to p= ut 'dns' or 'http' in it, then I think there will be a discussion to have a= bout that in the WG - and I don't want someone to just be able to say "we h= ave to have it because it's already in RFC 4474". And you know people say = things like that all the time in WG's, using the charter as a club to beat = down discussion. >=20 > -hadriel >=20 >=20 > On Jun 28, 2013, at 4:03 PM, "Peterson, Jon" w= rote: >=20 >>=20 >> I know, right?! >>=20 >> But seriously, there's a lot of "ifs" in your statement below. I'm >> concerned that if we start out with a non-goal of replacing RFC4474, we >> could duplicate a lot of design and effort and architecture (and pretty >> much text, even) and yet, in the name of parsimoniousness, end up with t= wo >> different flavors of verification and authentication services that as >> specifications need to be separately updated and kept in synch and so on= . >> I'd rather nip that at the bud. >>=20 >> Jon Peterson >> Neustar, Inc >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Fri Jun 28 14:28: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 A8C0421F9DB3 for ; Fri, 28 Jun 2013 14:28:01 -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 h7F+6uoowAev for ; Fri, 28 Jun 2013 14:27:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8224821F9DA1 for ; Fri, 28 Jun 2013 14:27:56 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SLRp6x020646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 14:27:54 -0700 Message-ID: <51CDFFCF.5040206@dcrocker.net> Date: Fri, 28 Jun 2013 14:27:43 -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: Eric Rescorla References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@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]); Fri, 28 Jun 2013 14:27:55 -0700 (PDT) Cc: stir@ietf.org, Dave Crocker Subject: Re: [stir] Out-of-band vs. in-band 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: Fri, 28 Jun 2013 21:28:01 -0000 Eric, On 6/28/2013 8:09 AM, Eric Rescorla wrote: > With that said, my impression going into that meeting and from the > discussion so far was that in fact for the foreseeable future we are > going to have environments where: > > (1) We want to have secure caller-id My conclusion, after some years of trying to carefully learn security terminology is that one of the words that has ceased to have any technical meaning is "secure". It's too vague. As Hadriel notes, there's a very specific bit of protection that is being targeted for STIR, with all sorts of other, appealing protection deemed out of scope. So for debating what to do or how to do it, we probably should try to be painfully precise in our labels, if only so that non-security pretenders like me can guess at what is really meant, with some hope of guessing correctly... The simple form as I understand it is to permit actors along the call setup path to validate authorization for the telephone number that is used in the From field. (Or whatever text made it into the current draft charter text.) > (2) We basically can't put anything meaningful in the messages that > go from caller to callee (I hasten to add that I don't know anywhere > near enough about SS7 to know if that's true, but that was my > impression). It's clear that's true for some portions of some scenarios. It's also clear that it's not true for other scenarios. > So, for the people who favor not doing a non-inband solution, do you > think that one of the two claims above is untrue? Or do you just > don't think it follows that we should be doing something about it? The range of issues that should move us towards a simplified initial focus is rather richer than just answering those two questions. They are useful, but not sufficient. > On 6/28/2013 8:48 AM, Eric Rescorla wrote:> >> Why is that true? A huge fraction of circuit switched devices are >> now smartphones, which could absolutely make use of such a >> mechanism. In fact, that's precisely the environment for which the >> system in question was designed. It is difficult to imagine that it would be wise to rely on smartphone adoption of anything new, such as an authentication method, in the critical path to anything near-term, or that focusing on smartphone usage initially would be the best point of leverage for a global forgery problem. Perhaps you know of some other global infrastructure security mechanism that has demonstrated a successful track record with such an approach? I'm also concerned that the goal seems to keep moving for the out-of-band mechanism. Its usage scenario seems to be different now than was cited in the original charter text, and the current one seems to have some impressive incremental overhead but with poor early-adopter benefits, thereby producing adoption disincentives. All in all, my own view is that it's turned into a relatively messy topic, with unclear likely benefits. In any event... In terms of strategy for managing productive IETF work, things go better when there is clear, initial focus on a single, narrow topic. Groups that try to juggle multiple topics simultaneously -- especially when they are essentially parallel mechanisms for the same problem -- tend to suffer the usual outcome of juggling too much, namely dropping /all/ the balls. EAI is the most reason example I've seen of getting distracted and confused by trying to design gatewaying to a different environment, at the same time as working on the the clean, core solution. They wound up with a dysfunctional hybrid that they were never able to clean up. And the discussion here, so far, between in-band and out-of-band, looked singularly unsatisfying to me. So the best thing for STIR is to start with the simplest, cleanest problem and produce the simplest, cleanest /useful/ design, as quickly as it reasonably can, and then proceed to add to it. That way it can field the initial stuff, while it is working on the incremental capabilities. For one thing, the smallest, narrowest, cleanest problem space is typically still quite challenging. And we are clearly already seeing that for the pure SIP-SIP discussion, such as concerning the From field, choices among query mechanism, and key-vs-credential retrieval. So even the simplest task for this topic involves some serious working group effort. If someone thinks that a pure SIP-SIP mechanism isn't useful, they should speak up. If someone thinks that a pure SIP-SIP mechanism is not the base upon which everything else should be build, they should speak up about that. Otherwise, it's difficult to see how that isn't the place to start. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.peterson@neustar.biz Fri Jun 28 14:38: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 1CDF921F9B00 for ; Fri, 28 Jun 2013 14:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.015 X-Spam-Level: X-Spam-Status: No, score=-106.015 tagged_above=-999 required=5 tests=[AWL=0.584, 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 U8Zz0JBL3Q-j for ; Fri, 28 Jun 2013 14:38:26 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0676721F9AFE for ; Fri, 28 Jun 2013 14:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372455450; x=1687807418; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=3LR1QaqV+t nCoY4R156r8MAr+1XJKIfHUrdPMqCkyUY=; b=QKTzT4PGOb0AaN9LRTrSZB+Q8S QPJEXI6zjX9+UAIS3S1QGhPCM1BG2cEdhCkB8Zc90lN315XqVKVIlMSt7mVQ== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21572749; Fri, 28 Jun 2013 17:37:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 17:38:11 -0400 From: "Peterson, Jon" To: Dan York , Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOAgAB77wD//5IYgIAAfe0A//+cewA= Date: Fri, 28 Jun 2013 21:38:10 +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.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vttEJ5FgVaO/oXRkpn6tmw== Content-Type: text/plain; charset="us-ascii" Content-ID: <9B7C548BAFC39C45A8656F10F963D87C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 21:38:30 -0000 >I hear what you are saying, Jon, but we've heard time and time again in >various conversations that RFC4474 is "not being deployed" and is not >being used because it has too many challenges in the way SIP systems are >deployed today. So it may be more accurate to say that we might end up >with: Those "challenges" are the elements STIR proposes to fix, which are the two I enumerated in my last mail. Or did you have some other challenges in mind? >1. one flavor of verification and authentication services that "nobody >uses" (RFC 4474) >2. one flavor of verification and authentication services that is focused >on telephone numbers (STIR) >And if this is the case I would ask if we really need to worry about #1 at >this point in time. Are we more likely to get this up in an expeditious manner by fixing the acknowledged problems with the existing work, or starting over from scratch? Or let me put it this way: Ddo you want to dispense with the concepts of an auth service and verification service, or a digest-string canonicalizing elements of a SIP request that's signed, or a credential for the signing authority? If all three of those seem like parts of the solution here, then you're building on RFC4474 whether you like or not. Sure, we could clone all of those concepts and text and build a spec that leaves out some parts (that we don't need to fixed or even changed) supporting greenfield identifiers, and then we'd have a resulting spec that is like your #2. And yes, in that case no one would use #1, agreed. Saying that "no one is using #1 because it doesn't have the fixes that we didn't put in #1" is a pretty good way to make sure you really don't need to worry about #1. If we are just building on the assumptions of an existing architecture, we could treat this work as incremental fixes to said architecture. It might be faster. And as I said in my last mail, a verification service will still have be aware of greenfield identifiers and SIP URI structures to do its job, you can't make SIP URIs not a part of the architecture. >Might it not be better to focus on getting a STIR solution out and THEN >look at a 4474bis that looks at the larger 4474 challenges and integrates >the STIR work into that larger work? There are no larger 4474 challenges other than the ones STIR proposes to fix, to my knowledge. Do tell, if you know differently. >My concern with adding a piece to the charter about replacing 4474 means >that it becomes yet one more thing that needs to be completed - and we >don't know if in fact a STIR solution will truly be able to replace 4474. >We might find that the simplest and most easily deployable solution for >STIR will not solve all the challenges of 4474 - and yet if the charter >says we need to replace 4474 we're then either trying to make it do so or >we're rechartering. A change to the scope of the digest-string necessarily means that the protection scope of a RFC4474bis won't be the same as RFC4474. It won't solve all the challenges of RFC4474. Saying that we're going to obsolete RFC4474 necessarily doesn't mean we're going to produce a protocol with identical properties: that would make the effort a complete waste of time. So again, I'm not sure what replacing RFC4447 really adds to the scope of work here. >Let's make the charter as simple and focused as possible. When we get to >where we have an agreed-upon solution we can decide if it can, in fact, >replace 4474 and can make that decision then. Read through the various drafts and pieces of charter text being proposed - I'm not sure I've seen anyone considering an in-band approach that does not effectively obsolete RFC4474. If we want the output of this working group to be what people do in the world instead of RFC4474, then we should obsolete RFC4474. Jon Peterson Neustar, Inc. >My 2 cents, >Dan > From jon.peterson@neustar.biz Fri Jun 28 14:45: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 53FBF21F9CD7 for ; Fri, 28 Jun 2013 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.161 X-Spam-Level: X-Spam-Status: No, score=-106.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 124PTpgD4K2u for ; Fri, 28 Jun 2013 14:45:47 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0376E21F9CE8 for ; Fri, 28 Jun 2013 14:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372455900; x=1687807418; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=K7DtbWyIsA QVQTBAXSDTHeMwabNxwImbE4GnhFmFans=; b=MPp7STTbgTI/kqKq0QMwaX+gmr Fis2e7kbZSixc3M2BNJlgDfmhmb9f6LjU+gtzVdkpzBUpxbEcmzm4aprwR5Q== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21573025; Fri, 28 Jun 2013 17:44:59 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 17:45:40 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlLiToAgAArZACAAAM/gP//liOAgAB77wD//5IYgIAAgdiA//+aqAA= Date: Fri, 28 Jun 2013 21:45:40 +0000 Message-ID: In-Reply-To: <1313DDB0-B92F-409A-82D0-5B96BFD88968@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: l1dHlDMMoeafuGoZIkslJw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19132435BF54D040910B5020499E94AF@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 21:45:51 -0000 > >OK, but I'm concerned that if we start out with a goal of replacing >RFC4474, that we're constrained to providing the same level of >protection, for the same information/aspects, against the same type of >attack vectors. I'm *not* concerned we'll have to protect the literal >From/To/Date/Call-ID/Cseq header field values, because I think we can >work around those, but I'm concerned that we'll be required to protect >bodies or even parts thereof. A valid concern, and I agree we should not be constrained to the same level of protection as RFC4474. In fact, the original proposed charter text called this out explicitly: "To conform with realistic deployments, we must also study ways to rebalance the requirements for the scope of RFC4474=B9s integrity protection to emphasize preventing third-party impersonation over preventing men-in-the-middle from capturing media." If you want it stronger than that, I don't object. I do think the right way to capture it is to get precise about the threat model and the precise types of impersonation we aspire to prevent. >And I *am* expecting to discuss design and architecture, and don't want >to be constrained to even having to support a URL model. Yes one could >put 'dns' in it, but if it would be up to the originator to decide >whether to put 'dns' or 'http' in it, then I think there will be a >discussion to have about that in the WG - and I don't want someone to >just be able to say "we have to have it because it's already in RFC >4474". And you know people say things like that all the time in WG's, >using the charter as a club to beat down discussion. Um. Hmm. Is there something that the Identity-Info URI model practically is preventing? I mean, the model is completely open - you don't even have to execute the URI, if you have an alternate way of getting credentials (as RFC4474 says). I was also vaguely imagining that an auth service could put multiple options in Identity-Info, if that helps. If you explain more what the concern is here, I'd certainly be open to finding the right language. Jon Peterson Neustar, Inc. >-hadriel > > >On Jun 28, 2013, at 4:03 PM, "Peterson, Jon" >wrote: > >>=20 >> I know, right?! >>=20 >> But seriously, there's a lot of "ifs" in your statement below. I'm >> concerned that if we start out with a non-goal of replacing RFC4474, we >> could duplicate a lot of design and effort and architecture (and pretty >> much text, even) and yet, in the name of parsimoniousness, end up with >>two >> different flavors of verification and authentication services that as >> specifications need to be separately updated and kept in synch and so >>on. >> I'd rather nip that at the bud. >>=20 >> Jon Peterson >> Neustar, Inc > From richard@shockey.us Fri Jun 28 14:47: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 71CC721F9CD8 for ; Fri, 28 Jun 2013 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.402 X-Spam-Level: X-Spam-Status: No, score=-99.402 tagged_above=-999 required=5 tests=[AWL=2.863, 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 ka-mFuew094c for ; Fri, 28 Jun 2013 14:47:21 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id B611A21F9CD7 for ; Fri, 28 Jun 2013 14:47:20 -0700 (PDT) Received: (qmail 21720 invoked by uid 0); 28 Jun 2013 21:47:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.unifiedlayer.com with SMTP; 28 Jun 2013 21:47:13 -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=w5phxZ7UbHQ/chbfsC5sbYX8S6Z5H+Qks4WNvzC/HtU=; b=Te+OjRDrJfv4Iq5rt5w/mfUypC5SwYXhXgDTMND3FT1Xa918yRNLgPyjw1fhadeFHGvA2iVjCusvoQGxxRR3FbRYm6XwNgi9/zDhfGCiFB7OnIdpZ+YLDuOvO/3TBoFt; Received: from [72.66.111.124] (port=53180 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UsgVc-0001in-Cd for stir@ietf.org; Fri, 28 Jun 2013 15:47:12 -0600 From: "Richard Shockey" To: References: <51CD1AC1.5010106@dcrocker.net> In-Reply-To: Date: Fri, 28 Jun 2013 17:47:10 -0400 Message-ID: <012a01ce7449$0b8abf40$22a03dc0$@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: AQEf7GlgLV4aowhQWvpSBYlNG0ELSpqossFA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Subject: Re: [stir] Revised charter text for 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, 28 Jun 2013 21:47:25 -0000 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Friday, June 28, 2013 4:59 PM To: dcrocker@bbiw.net Cc: stir@ietf.org Subject: Re: [stir] Revised charter text for STIR While I don't entirely agree with the account of numbering administration or assignment offered below, it certainly acknowledges that entities other than end users will sign for telephone identities. [RS> ] [RS> ] IMHO it's the carriers and their resellers will probably administer STIR like services this since we tend to write them checks and they are in a better position to do it. Even large enterprises will end up saying.. "To hell with this, I outsource everything these days .. go call ATT and have them do it. What do we pay them for anyway? This is some "cloud" thing." The point I raised about the proposed charter text was that I wasn't sure what actors it means where it reads that signing authority rests with "the entity formally assigned use of that number, or their delegate." I don't think there really is any formal assignment, there's a loose and sometimes convoluted process of delegation with many strange corner cases, and many numbers that aren't assigned to users at all. I don't think naming users as the font of authority, who then (implicitly, I guess) delegate to carriers authority to sign for numbers, is at all indicative of the deployment environment or the realities of numbering. [RS> ] [RS> ] Actually Jon is right here. We all understand numbering is a somewhat convoluted process where the end user has only a limited level of authority over his "E164 domain." And I use word domain deliberately. Even though you have portability rights over your NANP number for instance doesn't mean you can rewrite the 'zone files' in the NPAC. No one believes the system in the US or anywhere else is perfect, but it is what it is for now. To the eternal credit of the FCC, they are asking questions on how it could evolve given the realities of PSTN Transition. Don't delay file today! I have a Word template if you need one. It seems to me that, much like public ENUM, this language expresses a wish about how numbering should work; and like public ENUM, it would have to bend the realities of number administration, as infrastructure ENUM does, before a path to adoption became clear. Jon Peterson Neustar, Inc. On 6/27/13 10:10 PM, "Dave Crocker" wrote: >On 6/27/2013 5:40 PM, Peterson, Jon wrote: >>> No doubt, some signers will be telcos or other operators, and this >>>might seem confusing, but they are doing it /on behalf of/ the end >>>user. >>>Even >>> if real end users happen not to know their calls are being protected >>>with a signature on their behalf, it is on their behalf. It's not "by" >>> the operator. They are a delegate of the user. >> >> I think many people on this list would view telcos signing as the >>everyday case, and end-user signators as the exception. From an >>assignment perspective, carriers are certainly not (in contemporary >>North America >> anyway) delegates of the user; users are delegates of the carrier. >> Moreover there are plenty of other actors, like resellers, >>enterprises, etc who are also delegates and potentially signers. The >>problem again with the "the entity formally assigned use" language is >>that it treats the concept of "assignee" as if numbers have a single >>authority, but the reason "assignee" is a better term here than >>"owner" is because it doesn't have the connotation that there's some >>single authority. Numbering doesn't work that way. > > > >End users are not working "on behalf of" the provider. The term >"delegate" would mean they were... So, no, the end user is not a >delegate of the telco. > >It's important not to confuse the mechanics of some actions with the >roles being performed. We need to distinguish among several different >roles and several different actions and a couple of different >legitimization models. > > >Values are administered, possibly through a hierarchy. Ultimately, >they are assigned for 'use'. Look into a reverse white pages and you >won't find reference to the telco or Neustar. You'll find the user who >answers the phone. > >Administrators are not 'users'. Yeah, they mess with the value, but >they are performing support functions. > >Operators also perform some functions that touch the value. Back when >telephone numbers were tied to switch topology, of course, the >relationship was tighter. But again, they are not 'users'. They are >providers. The difference is fundamental. > >We need to avoid confusing support functions -- whether administration >or operations -- from assignment to the end-user. > >The history with telephone numbers has conflated a number of different >roles into the same set of actors. Number portability highlights that >they really are different roles. They further make clear that the >assignment of the number is detached from the telco that assigns it to >the end user. > >Yes, the number can be taken back from the end user, but not at the >whim of the telco. And it's generally not permitted to say 'owner' >when a continued licensing fee is required to retain rights. > > >Lastly is the role of vouching for validity. The end user can vouch >for their own use, because have that authority. But it's plausible >that others might do the vouching, either because the end user >delegated that right to them or because the services that check for >validity lend credence to some other agents. This moves from a simple, >objective assignment-based model for validation to one that looks more >like third-party reputation. > >So a telco doing signing is fine, either because they are doing it with >the user's implicit/explicit permission, or because the assessment >service chooses to treat the telco as a trusted agent. > >d/ > > > > >-- >Dave Crocker >Brandenburg InternetWorking >bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Fri Jun 28 14:53: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 1F0D621F9CEE for ; Fri, 28 Jun 2013 14:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=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 vNxVGUhsPsM6 for ; Fri, 28 Jun 2013 14:53:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC521F9D3E for ; Fri, 28 Jun 2013 14:53:04 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SLr0SA021185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 14:53:03 -0700 Message-ID: <51CE05B4.7020404@dcrocker.net> Date: Fri, 28 Jun 2013 14:52:52 -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: "Peterson, Jon" 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]); Fri, 28 Jun 2013 14:53:03 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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: Fri, 28 Jun 2013 21:53:09 -0000 On 6/28/2013 1:59 PM, Peterson, Jon wrote: > > While I don't entirely agree with the account of numbering administration > or assignment offered below, it certainly acknowledges that entities other > than end users will sign for telephone identities. Didn't know that was in question. Rather, the questions I saw were: who is doing signing on whose behalf and under what identifier? (I cited the case of a signature using an identifier other than the telephone number, in order to include the case of independently-trusted vouching services.) An example I forgot to include in my earlier rejoinder was the traveling doctor show. As with number portability, doctor portability highlights that vetting the number's use ultimately rests with the end user. > The point I raised > about the proposed charter text was that I wasn't sure what actors it > means where it reads that signing authority rests with "the entity > formally assigned use of that number, or their delegate." > I don't think > there really is any formal assignment, there's a loose and sometimes > convoluted process of delegation with many strange corner cases, Oh. Right. Whether a number leads to a particular person or enterprise answering the phone is always questionable? From one call to the next, it could land on anybody's phone, anywhere. Methinks you've imparted meaning to the words 'formal' and 'loose' that are a bit arcane for the current discussion. > and many > numbers that aren't assigned to users at all. I don't think naming users > as the font of authority, who then (implicitly, I guess) delegate to > carriers authority to sign for numbers, is at all indicative of the > deployment environment or the realities of numbering. You seem to be confusing operational norms with administrative truths. As I said earlier, there's certainly plenty of history to explain conflating the two, but they really are importantly separate topics, which things like number portability (and doctor portability) highlight. > It seems to me that, > much like public ENUM, this language expresses a wish about how numbering > should work;and like public ENUM, it would have to bend the realities of > number administration, as infrastructure ENUM does, before a path to > adoption became clear. I'm not understanding the reference to enum, in relation to the points I was making. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael.hammer@yaanatech.com Fri Jun 28 14:58: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 36DE921F9991 for ; Fri, 28 Jun 2013 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_43=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 v-V0Re6CSy95 for ; Fri, 28 Jun 2013 14:58:19 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20521F942B for ; Fri, 28 Jun 2013 14:58:18 -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, 28 Jun 2013 14:58:17 -0700 From: Michael Hammer To: "dcrocker@bbiw.net" , "jon.peterson@neustar.biz" Thread-Topic: [stir] Revised charter text for STIR Thread-Index: AQHOc0RMQjpB2TraA0SWDVW5gXHhNZlKO82AgAAQJQCAAFX4AIAAHRYAgABLaICAAQkLgIAADwoA//+Lq4A= Date: Fri, 28 Jun 2013 21:58:15 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBC0F67C@EX2K10MB1.corp.yaanatech.com> References: <51CE05B4.7020404@dcrocker.net> In-Reply-To: <51CE05B4.7020404@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.65] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0206_01CE740F.EAF02060" MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Revised charter text for 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, 28 Jun 2013 21:58:23 -0000 ------=_NextPart_000_0206_01CE740F.EAF02060 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit One side note. Please spell out whether auth means authentication or authorization. Often folks use the two inter-changeably, but there is a distinction. Authentication says you know who signed the assertion. Authorization says that who signed the assertion has the number delegation authority to do so. Mike -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Friday, June 28, 2013 2:53 PM To: Peterson, Jon Cc: stir@ietf.org Subject: Re: [stir] Revised charter text for STIR On 6/28/2013 1:59 PM, Peterson, Jon wrote: > > While I don't entirely agree with the account of numbering > administration or assignment offered below, it certainly acknowledges > that entities other than end users will sign for telephone identities. Didn't know that was in question. Rather, the questions I saw were: who is doing signing on whose behalf and under what identifier? (I cited the case of a signature using an identifier other than the telephone number, in order to include the case of independently-trusted vouching services.) An example I forgot to include in my earlier rejoinder was the traveling doctor show. As with number portability, doctor portability highlights that vetting the number's use ultimately rests with the end user. > The point I raised > about the proposed charter text was that I wasn't sure what actors it > means where it reads that signing authority rests with "the entity > formally assigned use of that number, or their delegate." > I don't think > there really is any formal assignment, there's a loose and sometimes > convoluted process of delegation with many strange corner cases, Oh. Right. Whether a number leads to a particular person or enterprise answering the phone is always questionable? From one call to the next, it could land on anybody's phone, anywhere. Methinks you've imparted meaning to the words 'formal' and 'loose' that are a bit arcane for the current discussion. > and many > numbers that aren't assigned to users at all. I don't think naming users > as the font of authority, who then (implicitly, I guess) delegate to > carriers authority to sign for numbers, is at all indicative of the > deployment environment or the realities of numbering. You seem to be confusing operational norms with administrative truths. As I said earlier, there's certainly plenty of history to explain conflating the two, but they really are importantly separate topics, which things like number portability (and doctor portability) highlight. > It seems to me that, > much like public ENUM, this language expresses a wish about how numbering > should work;and like public ENUM, it would have to bend the realities of > number administration, as infrastructure ENUM does, before a path to > adoption became clear. I'm not understanding the reference to enum, in relation to the points I was making. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_0206_01CE740F.EAF02060 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYy ODIxNTgxNVowIwYJKoZIhvcNAQkEMRYEFHtUFh2dYDwzGMd4EtNLo6fFvht7MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEABmMTtJeBkkVtbUz3HyH4H2Dedlp72NVxqBq7HHj2 GVKRIu0uyyZYdaz+XrZaQ7oCwgfORujHTZQXTGhvrQ2N43+Opo9i3oM+8W30ktBTo4WqrNMJkz7u FSiQGAveOs7N/sj/7E8GioIeR4lqoTPeVe2sG+C7gxBLHCOHpoG83wqUUFKm8CAzHD+MNqVIWnBD FrEcchzAzCXpyr4jczQnV7/LHppUFXTkM4Ts5aZCKE43NaLT4XqT6nHRUatMF2Dm6j/tRPIL8tdF kTCRxLJ9/G9So6bOhZ2Drs4YCi664qLYMO3mseyfH33K6n2nJINsY8+Hi96+h1Sq31m1kGje3gAA AAAAAA== ------=_NextPart_000_0206_01CE740F.EAF02060-- From jon.peterson@neustar.biz Fri Jun 28 15:20: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 B4B2221F9CDB for ; Fri, 28 Jun 2013 15:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 L9Na2tXp58fQ for ; Fri, 28 Jun 2013 15:20:31 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id B5B8721F9CDA for ; Fri, 28 Jun 2013 15:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372457925; x=1687814363; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=OAA2xyLtHz +NhKA9+IxHnrp6VHDUQlbkjS1e/pwyc+g=; b=b/OCje3iS+Fbx4oLi+IPYoPwUO EDemsYMaBspTQn7nBeZFccWV+bTlfYMKExh8D2yVTgSkpvI05LMKO4DGjCmQ== Received: from ([10.31.58.71]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.20136170; Fri, 28 Jun 2013 18:18:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 18:20:19 -0400 From: "Peterson, Jon" To: Hadriel Kaplan Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qTxOKj0KNUekSSEg+vw9zPGJlJylwAgACW4AD//6uKAIABwr+A//+ysYA= Date: Fri, 28 Jun 2013 22:20:18 +0000 Message-ID: In-Reply-To: <38870E27-BBCA-41E1-ABFF-B94647D7097D@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [192.168.128.174] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: klaQztf6Cc9iMqafZLdylA== Content-Type: text/plain; charset="us-ascii" Content-ID: <0B55059BC73C5F4D96E336AD10E42D86@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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, 28 Jun 2013 22:20:36 -0000 Replying out of order (the hail of mail is deafening out there): On 6/28/13 12:56 PM, "Hadriel Kaplan" wrote: >[part 2] > >On Jun 27, 2013, at 8:03 PM, "Peterson, Jon" >wrote: >>=20 >> But more materially, I am proposing that we create an optional hook for >> the deployments and scenarios where protecting some elements of bodies >> makes sense. I fully understand that there are deployments where it will >> not be practical, and I think we can make the hook quite unobtrusive for >> those deployments. > >Actually it's not unobtrusive. It reveals that carriers in the middle >changed the SDP. We need to design it in such a way that it's not that obtrusive. Roughly what I've been thinking is that the auth service should have the option to include more in its protection scope or not. I understand the sensitivity here about not revealing some changes to the SDP, and in environments where that's a concern, auth services simply will have to behave appropriately. Ultimately, I think the security treatment at verifiers of the two states a) "I don't know if the body was changed or not" and b) "I know the body was changed" should pretty much be the same anyway. A quick strawman: Follow the example of how RFC4474 treats the Contact header (which I know we need to move out of the digest-string, bear with me). Obviously Contact isn't present in every SIP request. If it is present, you add it to the digest-string; if not, you leave a gap in the digest-string for it (a "||"). That way, if the auth service didn't see one at signing time, no intermediary can add it later. So imagine there's a new optional header, Identity-Reliance or something. That header contains a sig over a separate digest-string, which for simplification's sake right now we'll say contains just the request body. We add a slot in the Identity digest-string for the signature that appears in the Identity-Reliance header field value. Thus, if you're an auth service, you have an -option- to construct an Identity-Reliance header. If you don't build one, you just leave a "||" in the Identity digest-string for the Identity-Reliance slot. So, if you're an auth service acting in a context where revealing SDP changes would be a problem, you simply don't include Identity-Reliance. If you're an intermediary in the middle who needs to surreptitiously change SDP, maybe if you see an Identity-Reliance header, you reject the request, perhaps even in a way that an auth service could (if policy permits) repair it - or if even that is too revealing, do some other sort of special treatment. And yes, I do think partial body protection for SDP is worth some study, and yes, I recognize that Identity-Reliance could be specified modularly and not even be a blocking dependency for the current work. We could define that slot in the digest string as "||" for now with a note to the effect that it is for future use and implementations should ignore it until told otherwise. Is that on the right track? >> My question to you is, are you so dedicated to the >> architecture of SIP request bodies being unprotected that you're >>unwilling >> to have even an option for this? > >Hah! I'm "dedicated to the architecture of SIP request bodies being >unprotected"?!? Yes I've dedicated my life to leaving SIP request bodies >unprotected. The Flying Spaghetti Monster himself came down and told me >to never protect SIP bodies. > > "For the FSM so hated the SIP request bodies, that whoever believes in > Him shall smite the evil bodies at all cost. For they are wicked >bodies=20 > full of IP Addresses, and port numbers, and other vile attributes." > - Kaplan 3:42 Okay, I deserved that. > >I don't know what I was possibly thinking when I wrote a draft that >allows for signing the SDP or relevant parts thereof: >http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity I know, I already wrote a note to this list about that draft. It's true it basically does have an option for signing SDP, admittedly one with slightly different properties than what I'd had in mind. So I'll take that to mean that you're fine having an option for SDP body protection. :) >Clearly I had a temporary crisis of faith at the the time. ;) > > >> I'm not sure why you're linking replay protection and body protection >>here >> - I didn't suggest they were connected in my mail. Replay protection is >> really a question of what headers are going to get signed. As I sent in >>a >> mail very early in the list, I didn't think from what I read in your >>draft >> that we're hugely far apart on this. > >Sorry for the confusion - I thought you were saying we needed to sign >bodies to prevent certain forms of cut-paste attacks. Obviously pure >"replay" attacks can be prevented regardless of SDP. I meant more >cut-paste attacks, as in the baiting-attack, which is a problem I do >worry about with even just caller-id reputability. Sure. Agreed that it does help to prevent some classes of attacks. I would be cautious about legislating that the mechanism we create in this working group can't provide any other security services as a side effect of its existence, but I do understand that we're agreeing not to take detours on our way to impersonation prevention. I don't think something along the Identity-Reliance lines would slow us down. Jon Peterson Neustar, Inc. >-hadriel > From fluffy@cisco.com Fri Jun 28 15:29: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 53B0C21F9D55 for ; Fri, 28 Jun 2013 15:29:02 -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 ETe9vs+aU3SL for ; Fri, 28 Jun 2013 15:28:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EE21F9CDC for ; Fri, 28 Jun 2013 15:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=598; q=dns/txt; s=iport; t=1372458536; x=1373668136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gpk9PkJJ9oyF2787dMPA3tkBWFCptDqTOqgw6bTwMv4=; b=m1lpMyBMz3ESKYWHM8uMP6jA39T0jkF/buVYbp4+ruPjPTR9rvO2OYPf p8NgxoU45I1+ly5E3Dotg0IuRNymK3q5e9daxmYZ3yF5IttoKDvJHPT2Y 5waB4psrnUbeHtcUFtjvpOQfB85zO1CsiO6hQ1WpTvhkRHOv0hI1DfZN2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKsMzlGtJV2b/2dsb2JhbABbgwl7vwqBChZ0giMBAQEDATo/BQsCAQgiFBAyJQIEDgUIiAEFAbpRjyMCMQeDBGMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="225842531" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 22:28:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5SMStRH031172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 22:28:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 17:28:55 -0500 From: "Cullen Jennings (fluffy)" To: "Rosen, Brian" Thread-Topic: [stir] Out of band Thread-Index: AQHOdE7ffZ5Xbw7SLk6bvvvHo6hNJQ== Date: Fri, 28 Jun 2013 22:28:55 +0000 Message-ID: References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> <61BDA3C1-70E8-458A-9F38-8C6F76DE0E80@neustar.biz> In-Reply-To: <61BDA3C1-70E8-458A-9F38-8C6F76DE0E80@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <9808D1B362FFA8448801D172EB5CA877@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 22:29:02 -0000 On Jun 20, 2013, at 8:46 AM, "Rosen, Brian" wrote= : > You misunderstood what I said, sorry for my part of the confusion. > What I meant was, no matter what we do, we are sure to have some SBCs man= gling whatever we need. It's inevitable. =20 I'll add to that with AFAIC, the bulk of deployed SBC are configured to rem= ove anything they don't understand. They may support other configurations b= ut practically speaking, they are often viewed as a security device and in = that use case most operators seem to remove things they don't understand. =20 From fluffy@cisco.com Fri Jun 28 15:29: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 DDD3921F9CDC for ; Fri, 28 Jun 2013 15:29:02 -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 SShMt44t3NAc for ; Fri, 28 Jun 2013 15:28:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D741321F9CC5 for ; Fri, 28 Jun 2013 15:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1372458536; x=1373668136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qx05YZPEgPX7ylZG/LodaYX6T1L+pyfmvzGogRa1tVk=; b=MCYANpvKC+yBZ6NurVcqPuZrC9flBPfJaDbHU/yRd5VrwzGoo5R7AP1I e5PHw9NSQp8YO4B3/KsR8sfTLPs4UF/GzDE5YyMgaMwn00n0k7FOBaGOJ bisvZVOAzHHQRngWRLK+bTEnb4hbXYiwzy3WyWvbzkiXszu13T0Ct8uxt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKsMzlGtJV2Y/2dsb2JhbABSCYMJe78KgQoWdIIjAQEBAwEnQBIFCwIBCCIkMiUCBA4FCBOHbgUBulGOGwOBBQIxBwKDAmMDqQqDEYFoAh4GGg X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="228844142" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jun 2013 22:28:56 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5SMSudF009244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 22:28:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 17:28:56 -0500 From: "Cullen Jennings (fluffy)" To: "Rosen, Brian" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHOdE7f1TWxNkjA10Gl9Agn9wmwdw== Date: Fri, 28 Jun 2013 22:28:55 +0000 Message-ID: References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <750F4E38-E126-4BE0-AD13-6B6EEF866DA3@neustar.biz> In-Reply-To: <750F4E38-E126-4BE0-AD13-6B6EEF866DA3@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.14] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6743BF77AD4F064DB46D06BB85942012@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan , "pp3129@att.com" , Michael Hammer Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 22:29:03 -0000 inline=20 On Jun 19, 2013, at 1:58 PM, "Rosen, Brian" wrote= : > To a certain extent, I agree, but it's also the case that we get a hair b= all out of solving every problem before we start work. >=20 > To me, the problems with EKR's idea, which I actually like quite a bit ar= e: > a) Only the origination can write the record. This might possibly be fix= able in some cases (SIP->SS7 GW is owned by a service provider who has the = number delegated to it, even though it delegated the number downstream). B= ut in a generic transit network case, it wouldn't work. With in-band, the = any provider in the path can verify. But only the termination entity (the = one who owns the credential) can validate. I think we could figure out ways to allow an authorized intermediary to do = this =85 > b) It depends (for stopping robocalling, vishing and swatting) on being a= ble to discover the credentials of the termination by the origination. Tha= t requires a public database of TN to cert. > I think the PERCEIVED difficulties of doing that doom deployment in any = interesting timeframe. I think many national regulators and national carri= ers will refuse to allow it. What would their primary concerns be? Just trying to get my head around all= the issues. We might be thinking about different things being revealed at = this level. I'm thinking that it would reveal that TN may or may not be ass= igned to a user but if it is, the public crypto key for that TN is X.=20 > I think many privacy advocates will object enough to slow deployment una= cceptably. Hmm - compared to the alternative of centralized global database that gets = all the information about who is calling who I'm not sure I agree. Be inter= esting to figure out the privacy issues of both types of designs.=20 >=20 > The problems with the alternate idea (SIP->SS7 writes, SS7->SIP queries, = restore the in band information) is that it has a more limited applicabilit= y, and must have a central DB. >=20 > There is another idea I've had for the problem of PSTN. First of all, n= ote that if the SIP->SS7 GW checked identity in band, it fixes the problem.= It doesn't have to be the termination device or carrier. Further, if ANY= entity in the path checks, it fixes the problem. That means SIP originati= on, PSTN termination can be addressed if we have at least one good SP in th= e path. I'm worried about that this will reduce to a hop by hop trust solution with= the trust level being the lowest common denominator which is more or less = what we have today. I've often made the point that the person that wishes t= he caller ID did not work is often the paying customer for a given carrier.= =20 From fluffy@cisco.com Fri Jun 28 15:29: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 D16EC21F9DA2 for ; Fri, 28 Jun 2013 15:29:13 -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 lMz3IMXg-pFz for ; Fri, 28 Jun 2013 15:29:08 -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 B2DC721F9CF5 for ; Fri, 28 Jun 2013 15:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=354; q=dns/txt; s=iport; t=1372458538; x=1373668138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IaJIub7IggAVrho5Dv0YFHythtfrXVNR9NDZRDQcenY=; b=EZsreqrhr5K2/UUxxdvKEbf4CmQMPL6OVxnlDZ4UMLtcGyzAom9T9enc /svyL0pJG0Iaw1Xcrb7pFQ+bbNhBfnA+VY52dD8N4VRypVsh7KK8UbHzC PDkJZ910ATwYmWInDEdYNzaNLu/j8wbo7ZqiivugIZghRAFEBRZjbBWQ8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKsMzlGtJXHA/2dsb2JhbABFFoMJe78KgQoWdIIjAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiIAQUBulGODYEWAjEHgwRjA6kKgxGCKA X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="228793535" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jun 2013 22:28:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5SMSwjm023156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 22:28:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 17:28:57 -0500 From: "Cullen Jennings (fluffy)" To: Anton Tveretin Thread-Topic: [stir] Some notes... Thread-Index: AQHOdE7gAzOgdAyy10CFgqF4ymHryg== Date: Fri, 28 Jun 2013 22:28:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BC08AB28A9D6040B08034CB8066632D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [stir] Some notes... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 22:29:14 -0000 On Jun 19, 2013, at 11:20 AM, Anton Tveretin wrote: > Why not hop-to-hop? This is how banking system works.=20 Uh, not that it matters but I thought a large amount of banking used mutual= ly trusted clearing houses - often created at a national legislature level = - or pairwise trust but very seldom multi hop trust.=20 From dhc@dcrocker.net Fri Jun 28 15:47: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 E294721F9A14 for ; Fri, 28 Jun 2013 15:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 b-QLj7X7EyJa for ; Fri, 28 Jun 2013 15:47:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E79F021F9A1F for ; Fri, 28 Jun 2013 15:47:22 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SMlI2F022231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 15:47:21 -0700 Message-ID: <51CE126E.7080300@dcrocker.net> Date: Fri, 28 Jun 2013 15:47:10 -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: Michael Hammer References: <42E86894-05FF-4D3B-B430-8E5660C44132@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0EFC1@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBC0EFC1@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]); Fri, 28 Jun 2013 15:47:21 -0700 (PDT) Cc: "fluffy@cisco.com" , "stir@ietf.org" , "hadriel.kaplan@oracle.com" , "jon.peterson@neustar.biz" Subject: Re: [stir] Replacing rfc4474 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: Fri, 28 Jun 2013 22:47:28 -0000 On 6/28/2013 11:32 AM, Michael Hammer wrote: > Perhaps the charter should have a requirement for extensibility. > > Then perhaps those other things can be added in later??? The challenge is to figure out what extensibility to call for. A generic reference to being extensible doesn't provide any real design guidance. Whereas, for example, "make the crypto algorithm choices extensible" does. Text that anticipates specific bits of needed extensibility might be quite helpful, if folks have particulars to offer. FWIW, the discussion that's been on the list so far hasn't suggested to me anything I'd call extensibility. The particular issue that prompted your note -- additional kinds of security functions we might want to add, after doing authorization validation for the telephone in the From field -- doesn't have obvious use that I can think of, for designing the initial mechanism. Perhaps others have suggestions? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Jun 28 16:09: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 2DD8C21F9D79 for ; Fri, 28 Jun 2013 16:09:50 -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 64-1kPlXBR3m for ; Fri, 28 Jun 2013 16:09:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECF321F9D78 for ; Fri, 28 Jun 2013 16:09:39 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SN9Yi7022998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 16:09:37 -0700 Message-ID: <51CE17A6.2090605@dcrocker.net> Date: Fri, 28 Jun 2013 16:09: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: "Peterson, Jon" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 28 Jun 2013 16:09:38 -0700 (PDT) Cc: "fluffy@cisco.com" , "hadriel.kaplan@oracle.com" , Michael Hammer , "stir@ietf.org" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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: Fri, 28 Jun 2013 23:09:50 -0000 On 6/28/2013 12:13 PM, Peterson, Jon wrote: > The argument that basing STIR on obsoleting RFC4474 adds new features > beyond the motivating requirements is powerful rhetoric, but divorced I > think from the actual reality of the IETF work before us. The fact is, we > have a body of prior work on authentication services and verification > services, on how to create, sign and validate digest-strings, and how to > determine signing authorities. I don't think I've heard anyone here (yet, > anyway) proposing an alternative architecture, just a change to the > digest-string and an addition to the types of signing authority. Choosing between publishing credentials versus publishing public keys is at least one example of competing choices that are quite basic in the design model for this authorization validation service. So, for example, using a DKIM-derived scheme is quite a different architecture from the one you've proposed. > The changes we need to make in STIR to the digest-string are, with one > exception, changes we would make regardless of whether or not the From > header field value contained a telephone number. They are changes that > will make this work with existing deployments. The one exception is the > canonicalization algorithm for telephone numbers we've discussed on the > list: that work is specific to telephone numbers. The experience with canonicalization algorithms for DKIM -- and it, too, had to deal with in-transit modifications -- makes clear that it's a topic with challenges and compromises. (Hmmm. "compromises" might be a pun, here.) > If we're fixing the rest > of the digest-string for the TN case, though, we should also fix it for > the greenfield case. The greenfield case doesn¹t introduce any new > requirements for this, say. It would not save us any work to treat this as > a separate effort from obsoleting the digest-string of RFC4474. I'm not understanding how concern for RFC4474 affects the technical work on this. > The addition of a new category of signing authority for telephone numbers > isn't even a wire protocol change, as I've previously pointed out. "new category of signing authority"? Sorry for my confusion, but I don't know what that means. > Identity-Info is already quite flexible in terms of what URI types it > supports (including potentially dns URIs). The new work that needs to be I missed where the DNS URI (dns:xxxxx) construct of RFC 4501 came into the discussion or how it's relevant. > done here is on how we compare the (canonicalized) From telephone number > with the authority of the signer. "compare the...number with the authority of the signer"? Apologies again but I'm not understanding what that means. How is "comparison with [an] authority" likely to play into validation? > But even the logic that inspects the >>From field to determine if it contains a telephone number needs to be > cognizant of the existence of greenfield identifiers, and trying to cast > this such that it operates in complete isolation from the world of > greenfield SIP URIs will not be conducive to a robust solution. Specify what it is to look for and that it is to ignore everything else, and things get pretty simple. It's like ignoring header fields that the processor doesn't know. And it has the advantage that it's both robust and simple. By the way, you seem to be using 'greenfield" as a well-recognized qualifier, but I can't find explanatory reference to it. Please explain. > I have a > hard time seeing an argument that it would be better to deploy > verification services that can only understand telephone numbers, given > the enormous overlap in functionality with understanding native SIP URIs, > and the fact that the standardization work on that is already done. If you said "large scale deployment and use work that is already done", that might be more telling... As for the referenced overlap, that bodes well for making the later, incremental work tractable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Jun 28 16:25: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 37E0821F9D78 for ; Fri, 28 Jun 2013 16:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GqYbFM9xhAZC for ; Fri, 28 Jun 2013 16:25:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 483EC21F9D67 for ; Fri, 28 Jun 2013 16:25:06 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-128-131.san.res.rr.com [76.93.128.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5SNP14Y023420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 16:25:04 -0700 Message-ID: <51CE1B45.3070908@dcrocker.net> Date: Fri, 28 Jun 2013 16:24:53 -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: "Cullen Jennings (fluffy)" References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@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]); Fri, 28 Jun 2013 16:25:05 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band 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: Fri, 28 Jun 2013 23:25:11 -0000 On 6/28/2013 8:48 AM, Cullen Jennings (fluffy) wrote: > I think we need both the modes to happen at same time as the incremental deployment of one greatly improves the chance of any deployment of the second mode. That's such a clear and forceful assertion, I'm motivated to ask for examples of times a similarly co-dependent deployment model has been successful for other global infrastructure efforts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.rosen@neustar.biz Fri Jun 28 16:35: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 8A73721F9CEA for ; Fri, 28 Jun 2013 16:35:43 -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 wiqnz6y+Gh3t for ; Fri, 28 Jun 2013 16:35:39 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2F28221F998B for ; Fri, 28 Jun 2013 16:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1372462492; x=1687807418; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=MquI5FRyF1 a1aL7p0H11utvzKZJLakYzx1euwAiehjY=; b=ZCDQW7mjCaBPRuAXE39ouCcXU8 ipfYFf+dWfrdQkuUL3L2YRjzP7/2oq6lrPNjqMbEmrSg2wX+m2wOI1D9uHLw== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.21576160; Fri, 28 Jun 2013 19:34:51 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 19:35:31 -0400 From: "Rosen, Brian" To: "Cullen Jennings (fluffy)" Thread-Topic: [stir] Do we agree on the basics? Thread-Index: AQHObPQxu1Sr6VHjzkyC0cy9zCtHMpk9D+AggAAFBlCAAEiZgIAAMYgAgAAHZoCADnB4gIAAEpoA Date: Fri, 28 Jun 2013 23:35:31 +0000 Message-ID: <6B1AAB45-8D54-4664-BD1A-0DB4A4455453@neustar.biz> References: <38726EDA2109264987B45E29E758C4D60495F251@MISOUT7MSGUSR9N.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3A03DEE49@ex2k10mb2.corp.yaanatech.com> <40D2B97D-87D3-4BE2-AED4-7E95339E51B7@neustar.biz> <275AD1DC-7BA9-4904-AC92-9F9D7D92408C@oracle.com> <750F4E38-E126-4BE0-AD13-6B6EEF866DA3@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.129.82] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Ie2wXiru0FJ0i7qwTT9+1g== Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Hadriel Kaplan , "pp3129@att.com" , Michael Hammer Subject: Re: [stir] Do we agree on the basics? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 23:35:43 -0000 On Jun 28, 2013, at 6:28 PM, Cullen Jennings (fluffy) wr= ote: >=20 > inline=20 >=20 > On Jun 19, 2013, at 1:58 PM, "Rosen, Brian" wro= te: >=20 >> To a certain extent, I agree, but it's also the case that we get a hair = ball out of solving every problem before we start work. >>=20 >> To me, the problems with EKR's idea, which I actually like quite a bit a= re: >> a) Only the origination can write the record. This might possibly be fi= xable in some cases (SIP->SS7 GW is owned by a service provider who has the= number delegated to it, even though it delegated the number downstream). = But in a generic transit network case, it wouldn't work. With in-band, the= any provider in the path can verify. But only the termination entity (the= one who owns the credential) can validate. >=20 > I think we could figure out ways to allow an authorized intermediary to d= o this =85 Do tell. The point of the cert delegation model was that it followed numbe= r delegation. Authorizing an intermediary that is a transit network would = be pretty tough to do I think. If the intermediary was in the delegation p= ath, it would work. >=20 >=20 >> b) It depends (for stopping robocalling, vishing and swatting) on being = able to discover the credentials of the termination by the origination. Th= at requires a public database of TN to cert. >> I think the PERCEIVED difficulties of doing that doom deployment in any = interesting timeframe. I think many national regulators and national carri= ers will refuse to allow it. >=20 > What would their primary concerns be? Just trying to get my head around a= ll the issues. We might be thinking about different things being revealed a= t this level. I'm thinking that it would reveal that TN may or may not be a= ssigned to a user but if it is, the public crypto key for that TN is X.=20 I think the problems aren't real, they are perceived. Who owns what numbe= r, which numbers are active, tracking people by observing the database oper= ations, walking the database to discover interesting patterns, and on and o= n. The minute it's public, we get a whole different level of scrutiny by a= lot of people who won't get the crypto details. I worry a lot about regul= ators and national carriers, for example. >=20 >=20 >> I think many privacy advocates will object enough to slow deployment una= cceptably. >=20 > Hmm - compared to the alternative of centralized global database that get= s all the information about who is calling who I'm not sure I agree. Be int= eresting to figure out the privacy issues of both types of designs.=20 If you are referring to my alternate idea, it's per nation with a LoST like= connection between national dbs. It's only accessible to trusted entities= . Many of the entities who would be worried about a public DB would be les= s worried about a DB that they had significant control over. >=20 >>=20 >> The problems with the alternate idea (SIP->SS7 writes, SS7->SIP queries,= restore the in band information) is that it has a more limited applicabili= ty, and must have a central DB. >>=20 >> There is another idea I've had for the problem of PSTN. First of all, = note that if the SIP->SS7 GW checked identity in band, it fixes the problem= . It doesn't have to be the termination device or carrier. Further, if AN= Y entity in the path checks, it fixes the problem. That means SIP originat= ion, PSTN termination can be addressed if we have at least one good SP in t= he path. >=20 > I'm worried about that this will reduce to a hop by hop trust solution wi= th the trust level being the lowest common denominator which is more or les= s what we have today. I've often made the point that the person that wishes= the caller ID did not work is often the paying customer for a given carrie= r.=20 Sure, but the closer you get to the termination, the more they care. All w= e need is ONE SP in the path that cares before the SS7 link. Note that EKRs idea makes it worse - either the origination endpoint or ori= gination SP has to write the record, no one else can. >=20 From br@brianrosen.net Fri Jun 28 16:46: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 827DD21F9DBC for ; Fri, 28 Jun 2013 16:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 xlXxbLBgM56g for ; Fri, 28 Jun 2013 16:46:02 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBF421F9DB6 for ; Fri, 28 Jun 2013 16:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=ngvCpFFAQDf7eKEnOpFFvNsWnWoCD0bHIEYpuh4gVaA=; b=BsZxYwoQ9oE0zTWZ8oZ5b8B/Q55O9g012O+1OatATdKp6nQfSetRCMqjZK9GXzE3QXhsB4mVFp9qnBHPcn/DV6aC4wWNj2JFjWa1rbbi8oaS/418YkjXAKqFGfs5d31342cbw6mS/E8tg1I33HUCJBp++/lpf3c9zgIvzWpfON8=; Received: from neustargw.va.neustar.com ([209.173.53.233]:48572 helo=[192.168.129.82]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UsiMT-0000hF-Lo; Fri, 28 Jun 2013 19:45:53 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <4EA91D96-B1AE-4FEE-9316-CB39046BD87D@oracle.com> Date: Fri, 28 Jun 2013 19:45:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01BBEAF8-F3DF-40CC-9DDB-12C5BBDD9591@brianrosen.net> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <7F50F3CE-BA50-45EE-8A40-45F778DF6A07@oracle.com> <0cc7f70e-d968-450b-bd25-c84fb2dff81d@email.android.com> <4EA91D96-B1AE-4FEE-9316-CB3 9046BD87D@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "Wendt, Chris" , Eric Rescorla , Dave Crocket , Richard Shockey , "stir@ietf.org" , Dave Crocker , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 23:46:07 -0000 We have a BoF approved, and we have chairs for the BoF. We'll deal with = consensus in the charter discussion at the BoF.=20 Brian On Jun 28, 2013, at 2:07 PM, Hadriel Kaplan = wrote: >=20 > On Jun 28, 2013, at 1:12 PM, Eric Rescorla wrote: >=20 >> This seems like a digression, but surely you know well that mailing >> list volume is not necessarily an accurate gauge of the views of >> the group. >=20 > Unfortunately that's all we have to go on for now. There is no WG. = (fwiw, ISTM that many WG's in the IETF do in fact use email volume to = gauge things, but I digress...) >=20 >=20 >> Regardless, I don't think that there has been a sufficient level of >> demonstrated consensus to justify the assertion of Hadriel's >> to which I was replying. >=20 > That's fair, and I should have been much more careful with what I said = - I should have been clearer that I didn't mean unanimous agreement - we = definitely do NOT have that. I meant it more as a "I believe the = majority opinion is..." =20 >=20 > And it's certainly possible my perception of a thinking even that is = wrong, and that we might be evenly divided instead, or that even the = majority might favor having both in-band and out-of-band in the charter. = I don't *think* that's the case, but I could be wrong. >=20 > I will say though that if I count the multiple personalities/voices in = my head, I outnumber all of you. ;) >=20 > -hadriel >=20 From md3135@att.com Fri Jun 28 16:52: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 1FBA521F9DC5 for ; Fri, 28 Jun 2013 16:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=1.964, 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 Dc9G9-fTOhW9 for ; Fri, 28 Jun 2013 16:51:57 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id E39E921F9A04 for ; Fri, 28 Jun 2013 16:51:38 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a812ec15.7d656940.323109.00-547.914043.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 28 Jun 2013 23:51:38 +0000 (UTC) X-MXL-Hash: 51ce218a68770f79-14ae548e2c94028fd721f93f609708e15344a83a Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a812ec15.0.323105.00-426.914028.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 28 Jun 2013 23:51:38 +0000 (UTC) X-MXL-Hash: 51ce218a3672df9c-7ef60d4b347d69acb64efebc96362ca24bb07bd7 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 r5SNpbSM004642; Fri, 28 Jun 2013 19:51:37 -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 r5SNpUQn004617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 19:51:33 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 23:51:04 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Fri, 28 Jun 2013 19:51:13 -0400 From: "DOLLY, MARTIN C" To: "Cullen Jennings (fluffy)" Thread-Topic: [stir] Out of band Thread-Index: AQHOdE7ffZ5Xbw7SLk6bvvvHo6hNJZlLzB+T Date: Fri, 28 Jun 2013 23:51:12 +0000 Message-ID: References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> <61BDA3C1-70E8-458A-9F38-8C6F76DE0E80@neustar.biz>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=J58dGnbS c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=Yh5l8hSFW2wA:10 a=AUd_NHdVAAAA:8 a=hGBaWAWWA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=SoeS6e0IPe9ybX71Cm8A:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 23:52:03 -0000 Cullen, please be a little less general=20 Martin Dolly AT&T=20 Sent from my iPhone On Jun 28, 2013, at 6:29 PM, "Cullen Jennings (fluffy)" = wrote: >=20 > On Jun 20, 2013, at 8:46 AM, "Rosen, Brian" wro= te: >=20 >> You misunderstood what I said, sorry for my part of the confusion. >> What I meant was, no matter what we do, we are sure to have some SBCs ma= ngling whatever we need. It's inevitable. =20 >=20 > I'll add to that with AFAIC, the bulk of deployed SBC are configured to r= emove anything they don't understand. They may support other configurations= but practically speaking, they are often viewed as a security device and i= n that use case most operators seem to remove things they don't understand. >=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Fri Jun 28 16:57: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 3292F21F9A71 for ; Fri, 28 Jun 2013 16:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=1.473, 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 qSTJ1kEh8xKo for ; Fri, 28 Jun 2013 16:57:54 -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 CEBCE21F9A5B for ; Fri, 28 Jun 2013 16:57:53 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 1032ec15.2aaad5c15940.6481422.00-528.18055824.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 23:57:53 +0000 (UTC) X-MXL-Hash: 51ce23015cddafe8-bbc15d6dc916e5d9b75f4c40648d51f8a1f08b07 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id df22ec15.0.6481405.00-335.18055768.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 28 Jun 2013 23:57:53 +0000 (UTC) X-MXL-Hash: 51ce23010c5120ee-5acc33e20f3ea773f9e728fd61211253b6d3ea4c 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 r5SNvn4K008110; Fri, 28 Jun 2013 19:57:49 -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 r5SNvjOn008085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 19:57:45 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 28 Jun 2013 23:57:29 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; Fri, 28 Jun 2013 19:57:37 -0400 From: "DOLLY, MARTIN C" To: "" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHOdFax9Ube0wumgUCN8mAR+HJsz5lLzdoj Date: Fri, 28 Jun 2013 23:57:37 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net>, , <51C89176.5000502@dcrocker.net> , <51CE1B45.3070908@dcrocker.net> In-Reply-To: <51CE1B45.3070908@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=b8OvNEjo] X-AnalysisOut: [AAAA:8 a=k7Ga1wGzAAAA:8 a=48vgC7mUAAAA:8 a=tkY1KDnq8CjGoCW] X-AnalysisOut: [l2P4A:9 a=CjuIK1q_8ugA:10 a=ClmATp4dOM8A:10 a=E1Snkw02GREA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10] Cc: "Cullen Jennings \(fluffy\)" , "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 23:57:59 -0000 Agree with Dave=20 Martin Dolly AT&T=20 Sent from my iPhone On Jun 28, 2013, at 7:25 PM, "Dave Crocker" wrote: > On 6/28/2013 8:48 AM, Cullen Jennings (fluffy) wrote: >> I think we need both the modes to happen at same time as the incremental= deployment of one greatly improves the chance of any deployment of the sec= ond mode. >=20 >=20 > That's such a clear and forceful assertion, I'm motivated to ask for exam= ples of times a similarly co-dependent deployment model has been successful= for other global infrastructure efforts. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From hadriel.kaplan@oracle.com Sat Jun 29 00:36: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 467B421F9D4B for ; Sat, 29 Jun 2013 00:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 UIIUdiUXMNlz for ; Sat, 29 Jun 2013 00:36:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C711521F9D2B for ; Sat, 29 Jun 2013 00:36:03 -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 r5T7TgpC013704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Jun 2013 07:29:43 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 r5T7a0V9001098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jun 2013 07:36:01 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5T7a0J6015990; Sat, 29 Jun 2013 07:36:00 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-164-249.vpn.oracle.com (/10.154.164.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Jun 2013 00:36:00 -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, 29 Jun 2013 03:35:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C1DA86.8040901@dcrocker.net> <2BE849F5-5113-4830-8E15-2BBC3AC8DA14@neustar.biz> <51C1E99A.6080507@dcrocker.net> <96A30171-345D-4BBD-B4EA-222BFC34560B@neustar.biz> <724962D7-FA9A-47C2-B47C-C314EC26CEEF@oracle.com> <61BDA3C1-70E8-458A-9F38-8C6F76DE0E80@neustar.biz> To: Cullen Jennings (fluffy) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Rosen, Brian" , "stir@ietf.org" Subject: Re: [stir] Out of band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jun 2013 07:36:10 -0000 On Jun 28, 2013, at 6:28 PM, Cullen Jennings (fluffy) = wrote: > On Jun 20, 2013, at 8:46 AM, "Rosen, Brian" = wrote: >=20 >> You misunderstood what I said, sorry for my part of the confusion. >> What I meant was, no matter what we do, we are sure to have some SBCs = mangling whatever we need. It's inevitable. =20 >=20 > I'll add to that with AFAIC, the bulk of deployed SBC are configured = to remove anything they don't understand. They may support other = configurations but practically speaking, they are often viewed as a = security device and in that use case most operators seem to remove = things they don't understand. I don't debate that from an Enterprise PBX's perspective that appears to = be the case: new headers they add don't make it through a carrier to = consumers/Enterprises elsewhere. Sometimes this is due to the security = policies on SBCs, sometimes due to behaviors of other B2BUAs in the = carriers. But afaik, for the inter-carrier peering SBCs it's not nearly as bad - = those SBCs usually are only configured to remove specific headers; so if = originating/terminating *carriers* are the ones to sign/verify, it won't = be as hard to add an Identity header to be let through among them. At = least in the sense that carriers have far fewer inter-carrier peering = points to have to do that with, than they do Enterprise trunks. = Especially if they have an incentive to let them through, and if they're = benign. For the other B2BUA devices, it appears to be usually harder than simple = configuration. My idealistic hope is that those vendors will someday = soon learn to simply have a configurable means of letting named headers = through, instead of having to wait for their next software release for = each specific new header name. But in their defense there aren't many = headers they've been able to simply handle in an opaque manner, so there = probably hasn't been much drive for such an ability. -hadriel From hadriel.kaplan@oracle.com Sat Jun 29 01:18: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 5E2B721F94FF for ; Sat, 29 Jun 2013 01:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, 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 yjySnesHCYwi for ; Sat, 29 Jun 2013 01:18:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEF921F925A for ; Sat, 29 Jun 2013 01:18: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 r5T8IOX5030462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Jun 2013 08:18:25 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5T8INZ0018697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jun 2013 08:18:24 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 r5T8INqa026242; Sat, 29 Jun 2013 08:18:23 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-164-249.vpn.oracle.com (/10.154.164.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Jun 2013 01:18:22 -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: Sat, 29 Jun 2013 04:18:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <388DA498-47F5-4F4E-BA9F-B57773447C77@oracle.com> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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: Sat, 29 Jun 2013 08:18:35 -0000 On Jun 28, 2013, at 5:45 PM, "Peterson, Jon" = wrote: >> And I *am* expecting to discuss design and architecture, and don't = want >> to be constrained to even having to support a URL model. Yes one = could >> put 'dns' in it, but if it would be up to the originator to decide >> whether to put 'dns' or 'http' in it, then I think there will be a >> discussion to have about that in the WG - and I don't want someone to >> just be able to say "we have to have it because it's already in RFC >> 4474". And you know people say things like that all the time in = WG's, >> using the charter as a club to beat down discussion. >=20 > Um. Hmm. Is there something that the Identity-Info URI model = practically > is preventing? I mean, the model is completely open - you don't even = have > to execute the URI, if you have an alternate way of getting = credentials > (as RFC4474 says). I was also vaguely imagining that an auth service = could > put multiple options in Identity-Info, if that helps. If you explain = more > what the concern is here, I'd certainly be open to finding the right > language. So are you saying that verifiers can basically just ignore the HTTP URL? = I hadn't noticed that exception before in RFC 4474. It seems really = weird to me to do that - I mean it sounds like an interop problem = waiting to happen - but I guess I'd be ok with having more unused header = fields floating around. -hadriel From richard@shockey.us Sat Jun 29 07:24: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 76B1311E8142 for ; Sat, 29 Jun 2013 07:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.356 X-Spam-Level: X-Spam-Status: No, score=-100.356 tagged_above=-999 required=5 tests=[AWL=1.909, 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 Dgi1k7FQKnzN for ; Sat, 29 Jun 2013 07:24:52 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9EACA21F9F50 for ; Sat, 29 Jun 2013 07:24:52 -0700 (PDT) Received: (qmail 10995 invoked by uid 0); 29 Jun 2013 14:24:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 29 Jun 2013 14:24:28 -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:Cc:To:From; bh=yyUj+tmZzLuFzhZDTF3DWiMsAsD+eQCqzF2bNO4BjxQ=; b=X50WkZAZw2LiZ9h25nzYRVEVD7fO04CWrS9Wc6/PYLh9v3R4X3ozzp3fBH6gpuLDCZN+ZNnyPlNixhXz3a6n7Wo3wKcWEhufyQ9e0yfF02b2prsHBV2K+1spWuNpGPK7; Received: from [72.66.111.124] (port=49322 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Usw4i-0000PI-8l; Sat, 29 Jun 2013 08:24:28 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Russ Housley'" , "'Richard Barnes'" Date: Sat, 29 Jun 2013 10:24:26 -0400 Message-ID: <003d01ce74d4$5c70ace0$155206a0$@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: Ac5006gt0l9GqCXKQyW6hBGEzkq4SQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us} Cc: stir@ietf.org Subject: [stir] BOF Requirements... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jun 2013 14:24:57 -0000 Seriously, you guys better request a really big room as well and a large time slot. You will have nearly the entire RAI and security communities attending. Needless to say don't schedule this against RTCWEB... :-) -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Friday, June 28, 2013 7:46 PM To: Hadriel Kaplan Cc: Wendt, Chris; Eric Rescorla; Dave Crocket; Richard Shockey; stir@ietf.org; Dave Crocker; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band We have a BoF approved, and we have chairs for the BoF. We'll deal with consensus in the charter discussion at the BoF. Brian On Jun 28, 2013, at 2:07 PM, Hadriel Kaplan wrote: > > On Jun 28, 2013, at 1:12 PM, Eric Rescorla wrote: > >> This seems like a digression, but surely you know well that mailing >> list volume is not necessarily an accurate gauge of the views of the >> group. > > Unfortunately that's all we have to go on for now. There is no WG. > (fwiw, ISTM that many WG's in the IETF do in fact use email volume to > gauge things, but I digress...) > > >> Regardless, I don't think that there has been a sufficient level of >> demonstrated consensus to justify the assertion of Hadriel's to which >> I was replying. > > That's fair, and I should have been much more careful with what I said - I should have been clearer that I didn't mean unanimous agreement - we definitely do NOT have that. I meant it more as a "I believe the majority opinion is..." > > And it's certainly possible my perception of a thinking even that is wrong, and that we might be evenly divided instead, or that even the majority might favor having both in-band and out-of-band in the charter. I don't *think* that's the case, but I could be wrong. > > I will say though that if I count the multiple personalities/voices in > my head, I outnumber all of you. ;) > > -hadriel > _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From dhc@dcrocker.net Sat Jun 29 07:48: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 1427621F9A79 for ; Sat, 29 Jun 2013 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 l0chnsDhj9Ty for ; Sat, 29 Jun 2013 07:48:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9F21F9A94 for ; Sat, 29 Jun 2013 07:48:19 -0700 (PDT) Received: from [192.168.1.116] (cpe-76-93-143-183.san.res.rr.com [76.93.143.183]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5TEmFqv003925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 Jun 2013 07:48:18 -0700 Message-ID: <51CEF3A7.508@dcrocker.net> Date: Sat, 29 Jun 2013 07:48:07 -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: Hadriel Kaplan References: <388DA498-47F5-4F4E-BA9F-B57773447C77@oracle.com> In-Reply-To: <388DA498-47F5-4F4E-BA9F-B57773447C77@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 29 Jun 2013 07:48:19 -0700 (PDT) Cc: "stir@ietf.org" Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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: Sat, 29 Jun 2013 14:48:24 -0000 On 6/29/2013 1:18 AM, Hadriel Kaplan wrote: > So are you saying that verifiers can basically just ignore the HTTP URL? I hadn't noticed that exception before in RFC 4474. It seems really weird to me to do that - I mean it sounds like an interop problem waiting to happen Not quite right. There's no 'waiting' about it. And it's deterministic. It defines the essence of a classic interop problem, with a signer using one method and a verifier requiring another. Complete disconnect. The usual model for IETF protocols, to avoid this, is to require everyone to use a common, core, basic capability, and then make others optional, as optimizations or enhancements. If the use of the alternative is to be /instead of/ the basic method, then there must be a prior negotiation between signer and verifier. Otherwise, the basic method is required. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hadriel.kaplan@oracle.com Sat Jun 29 11:16: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 2E45A11E8194 for ; Sat, 29 Jun 2013 11:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 sp4QPuIdp-Nc for ; Sat, 29 Jun 2013 11:15:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3E211E8177 for ; Sat, 29 Jun 2013 11:15:59 -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 r5TIFuUD027158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Jun 2013 18:15:57 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 r5TIFsX9026585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jun 2013 18:15:56 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5TIFsq4022302; Sat, 29 Jun 2013 18:15:54 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-177-41.vpn.oracle.com (/10.154.177.41) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 29 Jun 2013 11:15: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: <00C069FD01E0324C9FFCADF539701DB3BBC0EA94@EX2K10MB1.corp.yaanatech.com> Date: Sat, 29 Jun 2013 14:15:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <265BCEE1-6697-41D5-9B1D-C309BFFDFA84@oracle.com> References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <73D968BC-49DF-4F0F-8896-E1304A28C06F@oracle.com> <00C069FD01E0324C9FFCADF539701DB3BBC0E818@EX2K10MB1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBC0EA94@EX2K10MB1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "stir@ietf.org" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jun 2013 18:16:06 -0000 On Jun 28, 2013, at 12:21 PM, Michael Hammer = wrote: > To prove that A exists is not a proof that B cannot exist. Let's assume there is a B. Let's say that there exists an Edsel car = company somewhere receiving these complaint forms with completely wrong = numbers. They can't make heads or tails of them. How has Edsel been = using these contact numbers for anything meaningful today, if they're = nonsensical numbers? I.e., in what way is Edsel using the contact = number such that we can or need to provide a verification mechanism for = them? The problem that Edsel is having is different than our problem - = we're not being asked to fix received caller-id's being unintelligible; = we're being asked to provide a way for Dodge to know the E.164 contact = number they got in the complaint form is really the contact number of = the human who sent it. > Second, your analogy relies on the partial discipline of the PSTN, = that you > also later note can be intentionally broken. > What you don't yet recognize is that one can also unintentionally = break > things, unless some discipline removes the possibility (application of > Murphy's Law). The assumption I'm making for the "discipline of the PSTN" is that the = terminating domain can figure out what the source/dest E.164 phone = numbers are for requests they get, regardless of where they got them = from. If they don't, then STIR won't work for them, but that's not a = problem for STIR to fix. There are RFCs that tell them how to = syntactically format their URIs, and they can choose to use those to = solve that problem. But we don't need those syntactic forms to be used = end-to-end to get STIR to work. > Third, you assume that all senders and receivers know all others a = priori > and that all know each other's conventions. =20 > You have not yet proven that is a reasonable assumption. > While 100 years of history have allowed the accumulation of such = knowledge > in the PSTN, that doesn't transfer to the Internet. OK, let's ignore the way all SIP domain interconnect today. Let's = assume they behaved more like email, where essentially any domain can = send SIP requests to any other domain, without foreknowledge of = conventions. For that model to work at all, all domains must agree on = some common convention, or there has to be some protocol means for them = to negotiate/learn one to use. For example they could use TEL URLs for = E.164 numbers. STIR will function fine in that environment. STIR will = not function fine if they don't pick a common convention - but that's = not a fault of STIR nor a problem STIR is being formed to address/fix - = that would be a problem even if no one used STIR to begin with. > So, you need to get back to the fundamental question I am asking. > What data does the function at the receive side need to rely on, and = where > does it get that information? The data the function relies on are the E.164 phone numbers being used = (plus some other data to prevent replay/cut+paste, but that other data = can all be sent in the new header). The receive side gets that "data" from the To/From, but again the "data" = is E.164 numbers, not encoding strings. > The second you start assuming a priori out-of-band knowledge, this = breaks. > Unless you can show me how that knowledge can be learned upon receipt = of the > call, I am not buying it. Since the existing interconnection model does deliver caller-id in an = intelligible manner, and has for many years, it clearly hasn't broken = the second it was assumed. Don't get me wrong - it's not how we'd like = to do this stuff, clearly, but we need to focus on the problem at hand - = not a different problem that might happen someday. -hadriel From fas_vm@surguttel.ru Sat Jun 29 16:45: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 7487821F9D79 for ; Sat, 29 Jun 2013 16:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[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 2tlXTk62TrD8 for ; Sat, 29 Jun 2013 16:45:25 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 801B121F9E89 for ; Sat, 29 Jun 2013 16:45:25 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 183CA514FCF; Wed, 27 Feb 2013 17:24:48 +0600 (YEKT) Received: from Gateway (unknown [151.252.65.103]) by mail.s86.ru (Postfix) with ESMTPA id B3522514E2A for ; Wed, 27 Feb 2013 17:24:44 +0600 (YEKT) Message-ID: <69D15F2BBF2D42DC942355243605A033@Gateway> From: "Anton Tveretin" To: Date: Sun, 30 Jun 2013 05:35:16 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 8bit 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 130629-4, 30.06.2013), Outbound message X-Antivirus-Status: Clean Subject: [stir] Out-of-band vs. NGMTP X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 29 Jun 2013 23:45:31 -0000 So what is the scenario? Alice transmits INVITE through ùP say Atlanta. Atlanta deposits it and dispatches the message... Message distributed contains a reference to the original, but not necessarily all its headers. Anyone may fetch the original message (with NGMTP?) and check that it comes from Atlanta. This implies that original message is stored somewhere, available to anyone (at least any intermediate carrier, callee's carrier, callee, and even more if the call is forwarded). Also, there must be global IP-based network, to where all SIP-enabled carriers and their customers are connected to. This must not be "the Internet", strictly speaking. There are more issues. How long must server keep a message? What about E.164 addresses, indeed? I think forwarders and answerers deserve the same level of security, as callers. From Henning.Schulzrinne@fcc.gov Sun Jun 30 09:17: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 9B3CC21F9A87 for ; Sun, 30 Jun 2013 09:17:03 -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 DkvHYR5gtN05 for ; Sun, 30 Jun 2013 09:16:59 -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 4F56B21F9A84 for ; Sun, 30 Jun 2013 09:16:58 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan , "Peterson, Jon" Thread-Topic: [stir] Replacing rfc4474 (was: Revised charter text for STIR) Thread-Index: AQHOc2qfju36ah9Ux0e2HxhSF1PQN5lLiToAgAArZACAAAM/gIAAC30AgAAGlQCAAAd0AIAADHyAgAAQAwCAALDEAIAB02s5 Date: Sun, 30 Jun 2013 16:16:55 +0000 References: , <388DA498-47F5-4F4E-BA9F-B57773447C77@oracle.com> In-Reply-To: <388DA498-47F5-4F4E-BA9F-B57773447C77@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: "fluffy@cisco.com" , "stir@ietf.org" , Michael Hammer Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for 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: Sun, 30 Jun 2013 16:17:03 -0000 We do some version of this in every web browser and DNS resolver: If the da= ta is locally cached, no protocol request is made, along with other local c= aching mechanism where the HTTP or DNS request never reaches the origin ser= ver named, including both transparent and explicit (redirect) caching.=0A= =0A= As long as verifying entities have a way to fall back to retrieving content= via the URL at the designated location, this doesn't seem to affect intero= perability (and probably doesn't even need a detailed specification). As wi= th all caching mechanisms, there is a trade-off between extra querying and = possibly stale data.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hadriel Ka= plan [hadriel.kaplan@oracle.com]=0A= Sent: Saturday, June 29, 2013 4:18 AM=0A= To: Peterson, Jon=0A= Cc: fluffy@cisco.com; stir@ietf.org; Michael Hammer=0A= Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)= =0A= =0A= On Jun 28, 2013, at 5:45 PM, "Peterson, Jon" wro= te:=0A= =0A= >> And I *am* expecting to discuss design and architecture, and don't want= =0A= >> to be constrained to even having to support a URL model. Yes one could= =0A= >> put 'dns' in it, but if it would be up to the originator to decide=0A= >> whether to put 'dns' or 'http' in it, then I think there will be a=0A= >> discussion to have about that in the WG - and I don't want someone to=0A= >> just be able to say "we have to have it because it's already in RFC=0A= >> 4474". And you know people say things like that all the time in WG's,= =0A= >> using the charter as a club to beat down discussion.=0A= >=0A= > Um. Hmm. Is there something that the Identity-Info URI model practically= =0A= > is preventing? I mean, the model is completely open - you don't even have= =0A= > to execute the URI, if you have an alternate way of getting credentials= =0A= > (as RFC4474 says). I was also vaguely imagining that an auth service coul= d=0A= > put multiple options in Identity-Info, if that helps. If you explain more= =0A= > what the concern is here, I'd certainly be open to finding the right=0A= > language.=0A= =0A= =0A= So are you saying that verifiers can basically just ignore the HTTP URL? I= hadn't noticed that exception before in RFC 4474. It seems really weird t= o me to do that - I mean it sounds like an interop problem waiting to happe= n - but I guess I'd be ok with having more unused header fields floating ar= ound.=0A= =0A= -hadriel=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Sun Jun 30 11:50: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 D68BA21F9BEF for ; Sun, 30 Jun 2013 11:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=-2.946, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTFQpKQm2I4L for ; Sun, 30 Jun 2013 11:50:17 -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 A591E21F9B00 for ; Sun, 30 Jun 2013 11:50:16 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Eric Rescorla , Richard Shockey Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjU= Date: Sun, 30 Jun 2013 18:50:15 +0000 References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 18:50:26 -0000 The Google app store has several, if not dozens, of apps that query databas= es for incoming calls, for displaying related information and user-initiate= d blocking. To pick by download popularity, TrueCaller, Current Caller ID, = My Number-Block, WhosCall, Call Control, etc. (I have no idea how well any = of them work - I'm just copying names from the play.google.com web site...)= These obviously don't address callerID spoofing, but they query databases = for incoming calls. There are distinct issues with out-of-band mechanisms, but I doubt that use= r bandwidth or app availability are first-order concerns. ________________________________ From: Eric Rescorla [ekr@rtfm.com] Sent: Friday, June 28, 2013 1:28 PM To: Richard Shockey Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: This is not going to be generally true until the circuit switched network i= s mostly retired; customers hanging off a circuit switch aren=92t going to = be protected. Why is that true? A huge fraction of circuit switched devices are now smart= phones, which could absolutely make use of such a mechanism. In fact, that's precis= ely the environment for which the system in question was designed. [RS> ] Frankly I would doubt that. I would imagine the mobile operators a= nd Apple would object to anything that creates more signaling over the air.= Battery life. Its already an issue in VoLTE deployments. I have trouble = imagining any E2E scenarios in a first phase deployment and Penn is absolut= ely correct that there are not going to be any major retrofits of the legac= y networks, certainly not in North America. I'm really not following this. 1. We're talking about something on the order of 10KB of traffic/call. My iphone uses this much bandwidth every time it polls my email server. This has a trivial impact on battery life. 2. It doesn't need a retrofit of the network, just the phone software. That's the point. -Ekr From md3135@att.com Sun Jun 30 11:55: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 AC03021F99D9 for ; Sun, 30 Jun 2013 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=-1.767, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3, 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 ZGmi+7J6FLIw for ; Sun, 30 Jun 2013 11:54:56 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id C621221F893E for ; Sun, 30 Jun 2013 11:54:54 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id ffe70d15.48401940.900789.00-524.2489036.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 30 Jun 2013 18:54:55 +0000 (UTC) X-MXL-Hash: 51d07eff6b55f3ab-ec2184e9fd5a260e56abdb03c0f04182935edfbd Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dfe70d15.0.900787.00-274.2489023.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 30 Jun 2013 18:54:54 +0000 (UTC) X-MXL-Hash: 51d07efe0b34ca6e-456a1aafafbf8e7084d65a65623f2a3a424c5959 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 r5UIsr5N001768; Sun, 30 Jun 2013 14:54:53 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5UIsUEi001716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 14:54:42 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 18:54:20 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 14:54:30 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1g== Date: Sun, 30 Jun 2013 18:54:29 +0000 Message-ID: <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=J58dGnbS c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=1XWaLZrs] X-AnalysisOut: [AAAA:8 a=5IsXbjgYAAAA:8 a=48vgC7mUAAAA:8 a=6Muh_5q7TVMbpw8] X-AnalysisOut: [kNMMA:9 a=pILNOxqGKmIA:10 a=Dd_Pfn986HIA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=vRAbILRZcFsA:10 a=T-4eBWw2Ind4nSVP:21 a=KmFegIBDCVuh] X-AnalysisOut: [e3pj:21] Cc: "stir@ietf.org" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 18:55:01 -0000 Confused, so what is the problem space? Where does Google use SIP? Martin Dolly AT&T=20 Sent from my iPhone On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote: > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls. >=20 > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns. >=20 > ________________________________ > From: Eric Rescorla [ekr@rtfm.com] > Sent: Friday, June 28, 2013 1:28 PM > To: Richard Shockey > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band >=20 >=20 >=20 >=20 > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: >=20 >=20 >=20 > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren=92t going t= o be protected. >=20 > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones, > which could absolutely make use of such a mechanism. In fact, that's prec= isely > the environment for which the system in question was designed. >=20 > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America. >=20 >=20 > I'm really not following this. >=20 > 1. We're talking about something on the order of 10KB of traffic/call. > My iphone uses this much bandwidth every time it polls my email > server. This has a trivial impact on battery life. >=20 > 2. It doesn't need a retrofit of the network, just the phone software. > That's the point. >=20 > -Ekr >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Sun Jun 30 12:06: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 7248A21F9C32 for ; Sun, 30 Jun 2013 12:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=1.473, 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 L1WkSgN3PeZj for ; Sun, 30 Jun 2013 12:06:02 -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 61A3021F9C3E for ; Sun, 30 Jun 2013 12:05:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "PFAUTZ, PENN L" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAMYFdE= Date: Sun, 30 Jun 2013 19:05:51 +0000 References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> , <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 19:06:06 -0000 The details depend on the solution, but the out-of-band solutions discussed= all only assume that both end systems have Internet connectivity. For many= users, unknown callers (i.e., those not in their address book or call log)= are likely commercial entities that have both Internet connectivity and an= interest to make sure their calls are answered and not spoofed. This is not a comment on whether this should be a first-on-the-list or a re= chartering item, just that I think the constraints are a bit different than= stated. Also, I think it would be useful to consider how the same basic approach co= uld work for both "clear" (SIP) and obstructed (TDM) paths. If I understand= him correctly, Brian has been trying to get attention for that model. All = the basic information in the Identity-minus header (To/From/Date) seems to = survive non-IP paths, so this doesn't seem completely infeasible. Thus, rat= her than seeing in-band and out-of-band as necessarily divergent technologi= es and infrastructures, it might be interesting to explore whether there is= indeed some useful commonality. The phone system itself has and continues to operate both in in-band and ou= t-of-band mode and gradations in-between (MF as inband; ISDN as same-path, = different channel; SS7 and SIP as out-of-band), using compatible constructs= , so having multiple global interconnected infrastructures is not a new con= cept to telephony folks. ________________________________ From: PFAUTZ, PENN L [pp3129@att.com] Sent: Friday, June 28, 2013 11:37 AM To: Eric Rescorla; Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen;= Henning Schulzrinne Subject: RE: [stir] Out-of-band vs. in-band Eric: Here=92s the problem I see: The out of band solution assumes that there is = something at the terminating end that is able to make use of the out of ban= d mechanism. This is not going to be generally true until the circuit switc= hed network is mostly retired; customers hanging off a circuit switch aren= =92t going to be protected. Once we have end to end SIP we can do something in-band. People might like to have a rapid solution but I just don=92t see it happen= ing without major refits to the legacy network. So, I=92d prefer to concent= rate on getting things right in the new world, even if that world isn=92t c= oming as soon as any of us would like. Penn Pfautz AT&T Access Management +1-732-420-4962 From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Eri= c Rescorla Sent: Friday, June 28, 2013 11:10 AM To: Richard Shockey Cc: Wendt, Chris; Hadriel Kaplan; stir@ietf.org; Dave Crocker; Brian Rosen;= Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band [Semi-randomly picking a message to reply to...] First, let me say that I'm not at all wedded to anything in the proposal that bears my name and that I presented at the original STIR meeting. That proposal was designed to match a specific set of needs and if those needs aren't needed, then so much the better. With that said, my impression going into that meeting and from the discussion so far was that in fact for the foreseeable future we are going to have environments where: (1) We want to have secure caller-id (2) We basically can't put anything meaningful in the messages that go from caller to callee (I hasten to add that I don't know anywhere near enough about SS7 to know if that's true, but that was my impression). If that's true, then it seems like we really should be considering some non-inband solution from the get-go. So, for the people who favor not doing a non-inband solution, do you think that one of the two claims above is untrue? Or do you just don't think it follows that we should be doing something about it? Thanks, -Ekr On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey > wrote: +1 as well ... take it out of the charter. -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-boun= ces@ietf.org] On Behalf Of Wendt, Chris Sent: Tuesday, June 25, 2013 1:20 PM To: > Cc: stir@ietf.org; Brian Rosen; Hadriel Kaplan; Henni= ng Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band +1 On Jun 25, 2013, at 1:00 PM, Dave Crocker > wrote: >> If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter. We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups. We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF t= o do so successfully. >> >> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings. I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group. Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just bee= n to the wrong ones ;) > > > +1. > > Narrow, clear focus. > > Good. > > 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 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Sun Jun 30 12:10: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 0167421F9C42 for ; Sun, 30 Jun 2013 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.329 X-Spam-Level: * X-Spam-Status: No, score=1.329 tagged_above=-999 required=5 tests=[AWL=-1.964, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g--WdIwF52f9 for ; Sun, 30 Jun 2013 12:10:14 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id BB32E21F9C3E for ; Sun, 30 Jun 2013 12:10:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsb Date: Sun, 30 Jun 2013 19:10:12 +0000 References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> In-Reply-To: <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 19:10:18 -0000 I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 2:54 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= Confused, so what is the problem space? Where does Google use SIP?=0A= =0A= Martin Dolly=0A= AT&T=0A= =0A= Sent from my iPhone=0A= =0A= On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote:=0A= =0A= > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls.=0A= >=0A= > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns.=0A= >=0A= > ________________________________=0A= > From: Eric Rescorla [ekr@rtfm.com]=0A= > Sent: Friday, June 28, 2013 1:28 PM=0A= > To: Richard Shockey=0A= > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne=0A= > Subject: Re: [stir] Out-of-band vs. in-band=0A= >=0A= >=0A= >=0A= >=0A= > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote:=0A= >=0A= >=0A= >=0A= > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren=92t going t= o be protected.=0A= >=0A= > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones,=0A= > which could absolutely make use of such a mechanism. In fact, that's prec= isely=0A= > the environment for which the system in question was designed.=0A= >=0A= > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America.=0A= >=0A= >=0A= > I'm really not following this.=0A= >=0A= > 1. We're talking about something on the order of 10KB of traffic/call.=0A= > My iphone uses this much bandwidth every time it polls my email=0A= > server. This has a trivial impact on battery life.=0A= >=0A= > 2. It doesn't need a retrofit of the network, just the phone software.=0A= > That's the point.=0A= >=0A= > -Ekr=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= From Henning.Schulzrinne@fcc.gov Sun Jun 30 12:23: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 2596421F930C for ; Sun, 30 Jun 2013 12:23:37 -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=[AWL=-2.125, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, TVD_PH_REC=2.996] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3X2L3x0w8d0 for ; Sun, 30 Jun 2013 12:23:33 -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 E18BB21F8653 for ; Sun, 30 Jun 2013 12:23:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Hadriel Kaplan , Michael Hammer Thread-Topic: [stir] URI formats (was RE: Do we agree on the basics?) Thread-Index: AQHObdUE407rT0uZGkmimelssQZO+ZlANMEAgACC9wCABJqygIAA53cAgAByg4D//+QkiYAACfMwgABZMACAAAL+AIAAIBoAgADZkICAAF9KAIAAA26AgABG3V+AAEe1AIAACYUAgAAqmQCAAC/OAIAAvj2AgAAOJwCAABpsAIAAPHeAgAApGwCAACG7AIAALDWAgAPRQbE= Date: Sun, 30 Jun 2013 19:23:29 +0000 References: <00C069FD01E0324C9FFCADF539701DB3BBC0E4CE@EX2K10MB1.corp.yaanatech.com> <51CCD6C0.7050108@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBC0E6FE@EX2K10MB1.corp.yaanatech.com>, <2ABCC42C-CF00-4705-A5A1-0EB4D4AC7453@oracle.com> In-Reply-To: <2ABCC42C-CF00-4705-A5A1-0EB4D4AC7453@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" , "pkyzivat@alum.mit.edu" Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 19:23:37 -0000 +1=0A= =0A= Just in case this isn't plain to everyone: Today, the display of the text c= aller ID (212 555 1000 translates to "Joe's Pizza") is resolved at the rece= iving end, often by entities (CNAM databases) that have nothing to do with = either the calling or called carrier. This clearly works well enough, at le= ast for entities that don't want it to break. In our case, the good guys we= can validate have every interest in making it work. It also works well eno= ugh for call centers that routinely use that number to look up your account= record.=0A= =0A= Thus, unless somebody has specific evidence to the contrary in inter-carrie= r cases, maybe we can put this topic to rest. (We all seem to agree that lo= ts of odd numbering things happen within corporate or closed networks, but = they are not our problem.)=0A= =0A= ________________________________________=0A= From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf of Hadriel Ka= plan [hadriel.kaplan@oracle.com]=0A= Sent: Friday, June 28, 2013 12:59 AM=0A= To: Michael Hammer=0A= Cc: stir@ietf.org; pkyzivat@alum.mit.edu=0A= Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)=0A= =0A= I think you guys either keep missing the point, or you choose to ignore it.= The point is we have proof the concept can work, because things work toda= y.=0A= =0A= It simply can't be the case that domain A thinks a literal "X" means Y, and= domain B thinks literal "X" means Z, and that a message domain A sent had = "X" written on it and when B got it it still says "X". Because if that wer= e true, things wouldn't work right now - forget signing anything, or STIR, = or whatever. Domain A and B couldn't be communicating today if that were t= he case. Calls would be going to the wrong people all day. So clearly, by= the time domain B gets the message from domain A, the message must now say= something that means Y to domain B - it could be a literal "Y", or it coul= d be "W". It doesn't actually matter what the literal string is, so long a= s A and B both can figure out it means Y. And we're going to have domain A= sign as if it said Y all along, not the literal "X"; and we're going to ha= ve domain B verify for Y as well, not the literal "W" or whatever. We just= won't make them change whatever literal character it is they use on-the-wi= re already.=0A= =0A= I know it sucks - no one's saying it's the ideal world. It will probably t= ake some configuration, on the signing system or verifying system or both. = But that's better than changing configuration, code, or behavior of every = other system in all the domains at the same instant.=0A= =0A= And it's not as bad as it seems, either. It's not like people are changing= "+12125551212" into "djbDVbovur".=0A= :)=0A= =0A= -hadriel=0A= =0A= =0A= On Jun 27, 2013, at 10:21 PM, Michael Hammer = wrote:=0A= =0A= > But then you get the situation where:=0A= > A thinks X means Y, while=0A= > B thinks X means Z.=0A= > Verifying that it is truly X means different things to A and B.=0A= > So, A signs X and sends to B to confirm that the number is Y.=0A= > B verifies X and confirms that the number is Z.=0A= >=0A= > I don't think that is what we want.=0A= >=0A= > Mike=0A= =0A= _______________________________________________=0A= stir mailing list=0A= stir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/stir=0A= From md3135@att.com Sun Jun 30 12:55: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 27AC021F9C25 for ; Sun, 30 Jun 2013 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.653 X-Spam-Level: X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-2.946, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3, 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 WtSmz8+hnvQe for ; Sun, 30 Jun 2013 12:55:30 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 301D521F9C1B for ; Sun, 30 Jun 2013 12:55:30 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 23d80d15.5a61e940.914756.00-531.2527784.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 30 Jun 2013 19:55:30 +0000 (UTC) X-MXL-Hash: 51d08d325b5438e0-80554efc28745ff5cf8b2a49ea01684a4e2c1c98 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 13d80d15.0.914748.00-452.2527746.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 30 Jun 2013 19:55:29 +0000 (UTC) X-MXL-Hash: 51d08d316429a6f8-7034866c760b25c95bc67d1c2e84afc3b1e0625b 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 r5UJtRYl024808; Sun, 30 Jun 2013 15:55:29 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5UJt9BJ024679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 15:55:12 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 19:54:51 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 15:55:00 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1oAAR3IA///IVOA= Date: Sun, 30 Jun 2013 19:54:59 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.181] 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=J58dGnbS c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=PGVxqS49jJcA:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=bQRfyHg_r70A:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8] X-AnalysisOut: [ a=5IsXbjgYAAAA:8 a=7XK38SAwnhjMLniZzVoA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=Dd_Pfn986HIA:10 a] X-AnalysisOut: [=vRAbILRZcFsA:10 a=stMsEAfCruYt-Lws:21 a=9sd8DLOLuPwFXM8z:] X-AnalysisOut: [21] Cc: "stir@ietf.org" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 19:55:36 -0000 Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Sunday, June 30, 2013 3:10 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 2:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band Confused, so what is the problem space? Where does Google use SIP? Martin Dolly AT&T Sent from my iPhone On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote: > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls. > > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns. > > ________________________________ > From: Eric Rescorla [ekr@rtfm.com] > Sent: Friday, June 28, 2013 1:28 PM > To: Richard Shockey > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band > > > > > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: > > > > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected. > > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones, > which could absolutely make use of such a mechanism. In fact, that's prec= isely > the environment for which the system in question was designed. > > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America. > > > I'm really not following this. > > 1. We're talking about something on the order of 10KB of traffic/call. > My iphone uses this much bandwidth every time it polls my email > server. This has a trivial impact on battery life. > > 2. It doesn't need a retrofit of the network, just the phone software. > That's the point. > > -Ekr > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Sun Jun 30 13:02: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 CC8EF21F9C32 for ; Sun, 30 Jun 2013 13:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.245 X-Spam-Level: ** X-Spam-Status: No, score=2.245 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trw1NvPbpLdG for ; Sun, 30 Jun 2013 13:02:22 -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 879D421F9C33 for ; Sun, 30 Jun 2013 13:02:22 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+w== Date: Sun, 30 Jun 2013 20:02:20 +0000 References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.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" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:02:27 -0000 I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spuri= ous ring in some cases. These are real apps, not "what if". One of them cla= ims 18 million users.=0A= =0A= Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 3:54 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land.=0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Sunday, June 30, 2013 3:10 PM=0A= To: DOLLY, MARTIN C=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 2:54 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= Confused, so what is the problem space? Where does Google use SIP?=0A= =0A= Martin Dolly=0A= AT&T=0A= =0A= Sent from my iPhone=0A= =0A= On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote:=0A= =0A= > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls.=0A= >=0A= > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns.=0A= >=0A= > ________________________________=0A= > From: Eric Rescorla [ekr@rtfm.com]=0A= > Sent: Friday, June 28, 2013 1:28 PM=0A= > To: Richard Shockey=0A= > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne=0A= > Subject: Re: [stir] Out-of-band vs. in-band=0A= >=0A= >=0A= >=0A= >=0A= > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote:=0A= >=0A= >=0A= >=0A= > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected.=0A= >=0A= > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones,=0A= > which could absolutely make use of such a mechanism. In fact, that's prec= isely=0A= > the environment for which the system in question was designed.=0A= >=0A= > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America.=0A= >=0A= >=0A= > I'm really not following this.=0A= >=0A= > 1. We're talking about something on the order of 10KB of traffic/call.=0A= > My iphone uses this much bandwidth every time it polls my email=0A= > server. This has a trivial impact on battery life.=0A= >=0A= > 2. It doesn't need a retrofit of the network, just the phone software.=0A= > That's the point.=0A= >=0A= > -Ekr=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= From md3135@att.com Sun Jun 30 13:09: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 F12BF21F9A75 for ; Sun, 30 Jun 2013 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3, 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 Qfb4ZdKX2v9d for ; Sun, 30 Jun 2013 13:09:27 -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 E0F2121F99DB for ; Sun, 30 Jun 2013 13:09:26 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 67090d15.2aaabde02940.7075037.00-588.19671510.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:09:26 +0000 (UTC) X-MXL-Hash: 51d0907621a96bd8-95d65da0a92c42ec0b734e21f2f262cfef4f4632 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 47090d15.0.7075036.00-389.19671480.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:09:24 +0000 (UTC) X-MXL-Hash: 51d090743f8ffdd0-84f4f2d7db41f74f0d1408dca6949b9add5e8d52 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 r5UK9NL9031403; Sun, 30 Jun 2013 16:09:24 -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 r5UK9B95031355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 16:09:12 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 20:09:03 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 16:09:12 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1oAAR3IA///IVOAACMeoAAAIWHUw Date: Sun, 30 Jun 2013 20:09:11 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.181] 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=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=PGVxqS49jJcA:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=bQRfyHg_r70A:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8] X-AnalysisOut: [ a=5IsXbjgYAAAA:8 a=Jmd0Lr_RneH53oPUq-UA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=Dd_Pfn986HIA:10 a] X-AnalysisOut: [=vRAbILRZcFsA:10 a=oOMc_Lgo2XdlmEQn:21 a=TjqRuaHy2xdT4KX3:] X-AnalysisOut: [21] Cc: "stir@ietf.org" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:09:33 -0000 To hopefully be clearer, I do NOT invoke any app when I make or receive a c= all... I hope you are not saying that the IETF is creating a solution that requir= es me to invoke an app when I just want to make a Plain Old Phone call (POT= S), independent on whether my device is IP capable. I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Sunday, June 30, 2013 4:02 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spuri= ous ring in some cases. These are real apps, not "what if". One of them cla= ims 18 million users. Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 3:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, June 30, 2013 3:10 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 2:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band Confused, so what is the problem space? Where does Google use SIP? Martin Dolly AT&T Sent from my iPhone On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote: > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls. > > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns. > > ________________________________ > From: Eric Rescorla [ekr@rtfm.com] > Sent: Friday, June 28, 2013 1:28 PM > To: Richard Shockey > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band > > > > > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: > > > > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected. > > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones, > which could absolutely make use of such a mechanism. In fact, that's prec= isely > the environment for which the system in question was designed. > > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America. > > > I'm really not following this. > > 1. We're talking about something on the order of 10KB of traffic/call. > My iphone uses this much bandwidth every time it polls my email > server. This has a trivial impact on battery life. > > 2. It doesn't need a retrofit of the network, just the phone software. > That's the point. > > -Ekr > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From Henning.Schulzrinne@fcc.gov Sun Jun 30 13:16: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 1898D21F9BA5 for ; Sun, 30 Jun 2013 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.42 X-Spam-Level: ** X-Spam-Status: No, score=2.42 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-trAifML1ml for ; Sun, 30 Jun 2013 13:16:14 -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 B806021F9C4B for ; Sun, 30 Jun 2013 13:16:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaA//+9Pi8= Date: Sun, 30 Jun 2013 20:16:12 +0000 References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.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" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:16:18 -0000 The app invokes itself; as far as I can tell, the user phone behavior doesn= 't really change, i.e., you use the same phone interface as before and the = blocking app runs in the background.=0A= =0A= I think we all agree that a solution that does not require users to install= apps (and that works for feature phones and landlines) is preferable. Howe= ver, if a carrier infrastructure solution is not forthcoming, I wouldn't bl= ame users if they chose the second best alternative, even if it involves in= stalling apps. I'm encouraged by the extensive carrier participation in STI= R, so you may well get your wish (and may be in a position to help) of not = having to deal with apps.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 4:09 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= To hopefully be clearer, I do NOT invoke any app when I make or receive a c= all...=0A= =0A= I hope you are not saying that the IETF is creating a solution that requir= es me to invoke an app when I just want to make a Plain Old Phone call (POT= S), independent on whether my device is IP capable.=0A= =0A= I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it.=0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Sunday, June 30, 2013 4:02 PM=0A= To: DOLLY, MARTIN C=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spuri= ous ring in some cases. These are real apps, not "what if". One of them cla= ims 18 million users.=0A= =0A= Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 3:54 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land.=0A= =0A= -----Original Message-----=0A= From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=0A= Sent: Sunday, June 30, 2013 3:10 PM=0A= To: DOLLY, MARTIN C=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: RE: [stir] Out-of-band vs. in-band=0A= =0A= I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept.=0A= =0A= ________________________________________=0A= From: DOLLY, MARTIN C [md3135@att.com]=0A= Sent: Sunday, June 30, 2013 2:54 PM=0A= To: Henning Schulzrinne=0A= Cc: Eric Rescorla; Richard Shockey; stir@ietf.org=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= Confused, so what is the problem space? Where does Google use SIP?=0A= =0A= Martin Dolly=0A= AT&T=0A= =0A= Sent from my iPhone=0A= =0A= On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote:=0A= =0A= > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls.=0A= >=0A= > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns.=0A= >=0A= > ________________________________=0A= > From: Eric Rescorla [ekr@rtfm.com]=0A= > Sent: Friday, June 28, 2013 1:28 PM=0A= > To: Richard Shockey=0A= > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne=0A= > Subject: Re: [stir] Out-of-band vs. in-band=0A= >=0A= >=0A= >=0A= >=0A= > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote:=0A= >=0A= >=0A= >=0A= > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected.=0A= >=0A= > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones,=0A= > which could absolutely make use of such a mechanism. In fact, that's prec= isely=0A= > the environment for which the system in question was designed.=0A= >=0A= > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America.=0A= >=0A= >=0A= > I'm really not following this.=0A= >=0A= > 1. We're talking about something on the order of 10KB of traffic/call.=0A= > My iphone uses this much bandwidth every time it polls my email=0A= > server. This has a trivial impact on battery life.=0A= >=0A= > 2. It doesn't need a retrofit of the network, just the phone software.=0A= > That's the point.=0A= >=0A= > -Ekr=0A= >=0A= > _______________________________________________=0A= > stir mailing list=0A= > stir@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/stir=0A= From ekr@rtfm.com Sun Jun 30 13:18: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 23FF621F9C4E for ; Sun, 30 Jun 2013 13:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.031 X-Spam-Level: X-Spam-Status: No, score=-99.031 tagged_above=-999 required=5 tests=[AWL=-1.947, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 ySA6VzXV9v2V for ; Sun, 30 Jun 2013 13:18:03 -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 9747621F9BA5 for ; Sun, 30 Jun 2013 13:18:03 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so1652232qaj.3 for ; Sun, 30 Jun 2013 13:18:03 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Mdsk+f35QG3Rrw+psArDmaz+mjZQwXxoOZvfMaFRPcQ=; b=Tb86nO/xSMCOgqTzIRATvzCaE1aFI68I6tqVYmGmFXZf7XaW+VG1C8OA6vzEVw4bAN pJrPpT9r8GMnBiByUjO8TX8lH7XM+erqeLvFIah3VcDKg+447WtkTtVEoK8BJoxY2ReW mhP5cOTsl9EhLspkzBRtVSsir0bTbpqsHCW5QRPAAKJkCIQBtem7Owb1JuRK7vp8DsIl tVz5k9jN3VIRJwjsNZBOi7ujmKX1K9fW9xCHZMxJYmbf/9eiTF+jhQ6bVXvpS+0VfNl+ Nob3y71EFzam1SYd3GwUc77l2qaJMTwAfEmgDGQlez+m1UQg9B+rxmxczKjrvGPl59G1 kokQ== X-Received: by 10.229.242.131 with SMTP id li3mr6631813qcb.24.1372623483073; Sun, 30 Jun 2013 13:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Sun, 30 Jun 2013 13:17:23 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> From: Eric Rescorla Date: Sun, 30 Jun 2013 13:17:23 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=047d7b6767e41e89bb04e064cf7c X-Gm-Message-State: ALoCoQnTDbteyznNG4EL1ujkCtrKTcCocFv4N6ptIn9mON6QX0WCpts9A9OvMYcewzZVxKkqR2ng Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:18:08 -0000 --047d7b6767e41e89bb04e064cf7c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 30, 2013 at 1:09 PM, DOLLY, MARTIN C wrote: > To hopefully be clearer, I do NOT invoke any app when I make or receive a > call... > On a smartphone, the dialer generally is an app. For instance: https://wiki.mozilla.org/Gaia/Dialer -Ekr I hope you are not saying that the IETF is creating a solution that > requires me to invoke an app when I just want to make a Plain Old Phone > call (POTS), independent on whether my device is IP capable. > > I have an iPhone 5 and turn off all notifications and privilege for > location information, unless I need it. > > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Sunday, June 30, 2013 4:02 PM > To: DOLLY, MARTIN C > Cc: Eric Rescorla; Richard Shockey; stir@ietf.org > Subject: RE: [stir] Out-of-band vs. in-band > > I'm not quite following you. I haven't tried all (or most) of these apps, > but the ones I have seen get notified on inbound calls, fetch the > number-related information and then reject the call if found on the black > list. This works on Android; it may not work on IOS. Apparently, you may > get one spurious ring in some cases. These are real apps, not "what if". > One of them claims 18 million users. > > Maybe you can explain your concern in a bit more detail, as I'm obviously > not catching on. > > ________________________________________ > From: DOLLY, MARTIN C [md3135@att.com] > Sent: Sunday, June 30, 2013 3:54 PM > To: Henning Schulzrinne > Cc: Eric Rescorla; Richard Shockey; stir@ietf.org > Subject: RE: [stir] Out-of-band vs. in-band > > Understood what you said, you have not proven "existence proof", as when I > make a call on my mobile it does not interact with any other app, so how > does the "magic" happen for real, not "what if" land. > > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Sunday, June 30, 2013 3:10 PM > To: DOLLY, MARTIN C > Cc: Eric Rescorla; Richard Shockey; stir@ietf.org > Subject: RE: [stir] Out-of-band vs. in-band > > I said nothing about Google and using SIP, just that today there are > Android apps (not made by Google) that query an external database for every > call and use community rating to provide additional call-related > information or block the call as spam. This is essentially an out-of-band > solution in the same general problem space. It obviously doesn't address > caller ID spoofing (except for some lazy robocallers that spoof the same > number repeatedly - they exist), but provides an existence proof that > having an end system query a database per call is not a novel concept. > > ________________________________________ > From: DOLLY, MARTIN C [md3135@att.com] > Sent: Sunday, June 30, 2013 2:54 PM > To: Henning Schulzrinne > Cc: Eric Rescorla; Richard Shockey; stir@ietf.org > Subject: Re: [stir] Out-of-band vs. in-band > > Confused, so what is the problem space? Where does Google use SIP? > > Martin Dolly > AT&T > > Sent from my iPhone > > On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" < > Henning.Schulzrinne@fcc.gov> wrote: > > > The Google app store has several, if not dozens, of apps that query > databases for incoming calls, for displaying related information and > user-initiated blocking. To pick by download popularity, TrueCaller, > Current Caller ID, My Number-Block, WhosCall, Call Control, etc. (I have no > idea how well any of them work - I'm just copying names from the > play.google.com web site...) These obviously don't address callerID > spoofing, but they query databases for incoming calls. > > > > There are distinct issues with out-of-band mechanisms, but I doubt that > user bandwidth or app availability are first-order concerns. > > > > ________________________________ > > From: Eric Rescorla [ekr@rtfm.com] > > Sent: Friday, June 28, 2013 1:28 PM > > To: Richard Shockey > > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne > > Subject: Re: [stir] Out-of-band vs. in-band > > > > > > > > > > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: > > > > > > > > This is not going to be generally true until the circuit switched > network is mostly retired; customers hanging off a circuit switch aren't > going to be protected. > > > > Why is that true? A huge fraction of circuit switched devices are now > smartphones, > > which could absolutely make use of such a mechanism. In fact, that's > precisely > > the environment for which the system in question was designed. > > > > [RS> ] Frankly I would doubt that. I would imagine the mobile > operators and Apple would object to anything that creates more signaling > over the air. Battery life. Its already an issue in VoLTE deployments. I > have trouble imagining any E2E scenarios in a first phase deployment and > Penn is absolutely correct that there are not going to be any major > retrofits of the legacy networks, certainly not in North America. > > > > > > I'm really not following this. > > > > 1. We're talking about something on the order of 10KB of traffic/call. > > My iphone uses this much bandwidth every time it polls my email > > server. This has a trivial impact on battery life. > > > > 2. It doesn't need a retrofit of the network, just the phone software. > > That's the point. > > > > -Ekr > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > --047d7b6767e41e89bb04e064cf7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 30, 2013 at 1:09 PM, DOLLY, MARTIN C = <md3135@att.com&= gt; wrote:
To hopefully be clearer, I do NOT invoke any app when I ma= ke or receive a call...

On a smartphone, the dialer generall= y is an app. For instance:


-Ekr



I hope you are not saying that the IETF =A0is creating a solution that requ= ires me to invoke an app when I just want to make a Plain Old Phone call (P= OTS), independent on whether my device is IP capable.

I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it.

-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Sunday, June 30, 2013 4:02 PM=
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

I'm not quite following you. I haven't tried all (or most) of these= apps, but the ones I have seen get notified on inbound calls, fetch the nu= mber-related information and then reject the call if found on the black lis= t. This works on Android; it may not work on IOS. Apparently, you may get o= ne spurious ring in some cases. These are real apps, not "what if"= ;. One of them claims 18 million users.

Maybe you can explain your concern in a bit more detail, as I'm obvious= ly not catching on.

________________________________________
From: DOLLY, MARTIN C [md3135@att.com= ]
Sent: Sunday, June 30, 2013 3:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

Understood what you said, you have not proven "existence proof", = as when I make a call on my mobile it does not interact with any other =A0a= pp, so how does the "magic" happen for real, not "what if&qu= ot; land.

-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoo= fing (except for some lazy robocallers that spoof the same number repeatedl= y - they exist), but provides an existence proof that having an end system = query a database per call is not a novel concept.

________________________________________
From: DOLLY, MARTIN C [md3135@att.com= ]
Sent: Sunday, June 30, 2013 2:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: Re: [stir] Out-of-band vs. in-band

Confused, so what is the problem space? Where does Google use SIP?

Martin Dolly
AT&T

Sent from my iPhone

On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov> wr= ote:

> The Google app store has several, if not dozens, of apps that query da= tabases for incoming calls, for displaying related information and user-ini= tiated blocking. To pick by download popularity, TrueCaller, Current Caller= ID, My Number-Block, WhosCall, Call Control, etc. (I have no idea how well= any of them work - I'm just copying names from the play.google.com web site...) These ob= viously don't address callerID spoofing, but they query databases for i= ncoming calls.
>
> There are distinct issues with out-of-band mechanisms, but I doubt tha= t user bandwidth or app availability are first-order concerns.
>
> ________________________________
> From: Eric Rescorla [ekr@rtfm.com]=
> Sent: Friday, June 28, 2013 1:28 PM
> To: Richard Shockey
> Cc: stir@ietf.org; Dave Crocker; = Henning Schulzrinne
> Subject: Re: [stir] Out-of-band vs. in-band
>
>
>
>
> On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <richard@shockey.us<mailto:richard@shockey.us>> wrote:
>
>
>
> This is not going to be generally true until the circuit switched netw= ork is mostly retired; customers hanging off a circuit switch aren't go= ing to be protected.
>
> Why is that true? A huge fraction of circuit switched devices are now = smartphones,
> which could absolutely make use of such a mechanism. In fact, that'= ;s precisely
> the environment for which the system in question was designed.
>
> [RS> ] =A0Frankly I would doubt that. =A0I would imagine the mobile= operators and Apple would object to anything that creates more signaling o= ver the air. =A0Battery life. Its already an issue in VoLTE deployments. = =A0I have trouble imagining any E2E scenarios in a first phase deployment a= nd Penn is absolutely correct that there are not going to be any major retr= ofits of the legacy networks, certainly not in North America.
>
>
> I'm really not following this.
>
> 1. We're talking about something on the order of 10KB of traffic/c= all.
> My iphone uses this much bandwidth every time it polls my email
> server. This has a trivial impact on battery life.
>
> 2. It doesn't need a retrofit of the network, just the phone softw= are.
> That's the point.
>
> -Ekr
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

--047d7b6767e41e89bb04e064cf7c-- From md3135@att.com Sun Jun 30 13: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 DDCF221F9C0A for ; Sun, 30 Jun 2013 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, FRT_PENIS1=3.592, MANGLED_PENIS=2.3, 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 QypYRI7w1KeC for ; Sun, 30 Jun 2013 13:18:40 -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 D7D2E21F8ECE for ; Sun, 30 Jun 2013 13:18:39 -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 f9290d15.62733940.6707677.00-566.18685476.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:18:39 +0000 (UTC) X-MXL-Hash: 51d0929f632b869b-168a11288e3c2d6593815d637d3108d9ffcb0de3 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 f9290d15.0.6707675.00-266.18685461.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:18:39 +0000 (UTC) X-MXL-Hash: 51d0929f4243aa16-c0331342662e42c6eb1700f64298c84247c1e4d5 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 r5UKIch1003652; Sun, 30 Jun 2013 16:18:38 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5UKIQfu003531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 16:18:28 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 20:18:16 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 16:18:25 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1oAAR3IA///IVOAACMeoAAAIWHUw///BHACAAELcEA== Date: Sun, 30 Jun 2013 20:18:24 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us>, , , <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.181] 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=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=PGVxqS49jJcA:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=bQRfyHg_r70A:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8] X-AnalysisOut: [ a=5IsXbjgYAAAA:8 a=jvy83w5_zKTi-_7q3nMA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=Dd_Pfn986HIA:10 a] X-AnalysisOut: [=vRAbILRZcFsA:10 a=uz22pAPYXDhKoORw:21 a=-yUaqGsuZsXtqjBx:] X-AnalysisOut: [21] Cc: "stir@ietf.org" , Eric Rescorla , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:18:46 -0000 I really do not want apps that invoke themselves...it is a little thing cal= led security/privacy. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Sunday, June 30, 2013 4:16 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band The app invokes itself; as far as I can tell, the user phone behavior doesn= 't really change, i.e., you use the same phone interface as before and the = blocking app runs in the background. I think we all agree that a solution that does not require users to install= apps (and that works for feature phones and landlines) is preferable. Howe= ver, if a carrier infrastructure solution is not forthcoming, I wouldn't bl= ame users if they chose the second best alternative, even if it involves in= stalling apps. I'm encouraged by the extensive carrier participation in STI= R, so you may well get your wish (and may be in a position to help) of not = having to deal with apps. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 4:09 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band To hopefully be clearer, I do NOT invoke any app when I make or receive a c= all... I hope you are not saying that the IETF is creating a solution that requir= es me to invoke an app when I just want to make a Plain Old Phone call (POT= S), independent on whether my device is IP capable. I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, June 30, 2013 4:02 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spuri= ous ring in some cases. These are real apps, not "what if". One of them cla= ims 18 million users. Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 3:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, June 30, 2013 3:10 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 2:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band Confused, so what is the problem space? Where does Google use SIP? Martin Dolly AT&T Sent from my iPhone On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" wrote: > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site..= .) These obviously don't address callerID spoofing, but they query database= s for incoming calls. > > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns. > > ________________________________ > From: Eric Rescorla [ekr@rtfm.com] > Sent: Friday, June 28, 2013 1:28 PM > To: Richard Shockey > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band > > > > > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey > wrote: > > > > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected. > > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones, > which could absolutely make use of such a mechanism. In fact, that's prec= isely > the environment for which the system in question was designed. > > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America. > > > I'm really not following this. > > 1. We're talking about something on the order of 10KB of traffic/call. > My iphone uses this much bandwidth every time it polls my email > server. This has a trivial impact on battery life. > > 2. It doesn't need a retrofit of the network, just the phone software. > That's the point. > > -Ekr > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From md3135@att.com Sun Jun 30 13:21: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 1598821F9C2D for ; Sun, 30 Jun 2013 13:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, 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 wvxFdmfs6Cur for ; Sun, 30 Jun 2013 13:20:57 -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 465AA21F8ECE for ; Sun, 30 Jun 2013 13:20:57 -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 92390d15.72b4d940.6708086.00-511.18686567.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:20:57 +0000 (UTC) X-MXL-Hash: 51d093293f9144d6-ee47419b95a937128343af60ae98d309b0a005dc 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 82390d15.0.6708083.00-468.18686557.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 30 Jun 2013 20:20:56 +0000 (UTC) X-MXL-Hash: 51d0932825b2812f-ef09eb41b838feb8b82b7debfe9578a3d842d555 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 r5UKKt5t004503; Sun, 30 Jun 2013 16:20:56 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5UKKoft004481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 16:20:50 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 20:20:35 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 16:20:45 -0400 From: "DOLLY, MARTIN C" To: Eric Rescorla Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1oAAR3IA///IVOAACMeoAAAIWHUw///BcICAAEKdUA== Date: Sun, 30 Jun 2013 20:20:44 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.181] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656021D70D6MISOUT7MSGUSR9I_" 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=A9DbydqG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=PGVxqS49jJcA:10 a=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=bQRfyHg_r] X-AnalysisOut: [70A:10 a=5IsXbjgYAAAA:8 a=48vgC7mUAAAA:8 a=pQs5aej7AAAA:8 ] X-AnalysisOut: [a=1XWaLZrsAAAA:8 a=tB_qjEUza00a1YUwoTYA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=Dd_Pfn986HIA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=] X-AnalysisOut: [vRAbILRZcFsA:10 a=6ylTFaLdb7MfUrSW:21 a=oY3NS9ld_zY9EKuw:2] X-AnalysisOut: [1 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=XDWzZlYP-YFL_idODbQA] X-AnalysisOut: [:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a] X-AnalysisOut: [=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=yrdKorcb5bwA:10 a=8hd] X-AnalysisOut: [oNGGH-zl8KVVM:21 a=Afpvacsv4m1-8wUC:21 a=Jv0w-K-peWeA91s7:] X-AnalysisOut: [21] Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:21:03 -0000 --_000_E42CCDDA6722744CB241677169E83656021D70D6MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, My mother picks up her phone and she dials a number...no app, even though s= he has a smart phone. This is the user we have to protect... do you agree? Thank you, Martin From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Sunday, June 30, 2013 4:17 PM To: DOLLY, MARTIN C Cc: Henning Schulzrinne; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band On Sun, Jun 30, 2013 at 1:09 PM, DOLLY, MARTIN C > wrote: To hopefully be clearer, I do NOT invoke any app when I make or receive a c= all... On a smartphone, the dialer generally is an app. For instance: https://wiki.mozilla.org/Gaia/Dialer -Ekr I hope you are not saying that the IETF is creating a solution that requir= es me to invoke an app when I just want to make a Plain Old Phone call (POT= S), independent on whether my device is IP capable. I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, June 30, 2013 4:02 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spuri= ous ring in some cases. These are real apps, not "what if". One of them cla= ims 18 million users. Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 3:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band Understood what you said, you have not proven "existence proof", as when I = make a call on my mobile it does not interact with any other app, so how d= oes the "magic" happen for real, not "what if" land. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, June 30, 2013 3:10 PM To: DOLLY, MARTIN C Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: RE: [stir] Out-of-band vs. in-band I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the = same general problem space. It obviously doesn't address caller ID spoofing= (except for some lazy robocallers that spoof the same number repeatedly - = they exist), but provides an existence proof that having an end system quer= y a database per call is not a novel concept. ________________________________________ From: DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, June 30, 2013 2:54 PM To: Henning Schulzrinne Cc: Eric Rescorla; Richard Shockey; stir@ietf.org Subject: Re: [stir] Out-of-band vs. in-band Confused, so what is the problem space? Where does Google use SIP? Martin Dolly AT&T Sent from my iPhone On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" > wrote: > The Google app store has several, if not dozens, of apps that query datab= ases for incoming calls, for displaying related information and user-initia= ted blocking. To pick by download popularity, TrueCaller, Current Caller ID= , My Number-Block, WhosCall, Call Control, etc. (I have no idea how well an= y of them work - I'm just copying names from the play.google.com web site...) These obviously don't address callerID spoofing,= but they query databases for incoming calls. > > There are distinct issues with out-of-band mechanisms, but I doubt that u= ser bandwidth or app availability are first-order concerns. > > ________________________________ > From: Eric Rescorla [ekr@rtfm.com] > Sent: Friday, June 28, 2013 1:28 PM > To: Richard Shockey > Cc: stir@ietf.org; Dave Crocker; Henning Schulzrinn= e > Subject: Re: [stir] Out-of-band vs. in-band > > > > > On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey >> wrote: > > > > This is not going to be generally true until the circuit switched network= is mostly retired; customers hanging off a circuit switch aren't going to = be protected. > > Why is that true? A huge fraction of circuit switched devices are now sma= rtphones, > which could absolutely make use of such a mechanism. In fact, that's prec= isely > the environment for which the system in question was designed. > > [RS> ] Frankly I would doubt that. I would imagine the mobile operators= and Apple would object to anything that creates more signaling over the ai= r. Battery life. Its already an issue in VoLTE deployments. I have troubl= e imagining any E2E scenarios in a first phase deployment and Penn is absol= utely correct that there are not going to be any major retrofits of the leg= acy networks, certainly not in North America. > > > I'm really not following this. > > 1. We're talking about something on the order of 10KB of traffic/call. > My iphone uses this much bandwidth every time it polls my email > server. This has a trivial impact on battery life. > > 2. It doesn't need a retrofit of the network, just the phone software. > That's the point. > > -Ekr > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_E42CCDDA6722744CB241677169E83656021D70D6MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 <= /p>

My mother picks up her ph= one and she dials a number…no app, even though she has a smart phone.= This is the user we have to protect… do you agree?=

 <= /p>

Thank you,

 <= /p>

Martin<= /p>

 <= /p>

From: Eric Res= corla [mailto:ekr@rtfm.com]
Sent: Sunday, June 30, 2013 4:17 PM
To: DOLLY, MARTIN C
Cc: Henning Schulzrinne; Richard Shockey; stir@ietf.org
Subject: Re: [stir] Out-of-band vs. in-band

 

 

 

On Sun, Jun 30, 2013 at 1:09 PM, DOLLY, MARTIN C <= ;md3135@att.com>= wrote:

To hopefully be clearer, I do NOT invoke any app whe= n I make or receive a call...

 

On a smartphone, the dialer generally is an app. For= instance:

 

 

-Ekr

 

 

 

I hope you are not saying that the IETF  is cre= ating a solution that requires me to invoke an app when I just want to make= a Plain Old Phone call (POTS), independent on whether my device is IP capa= ble.

I have an iPhone 5 and turn off all notifications and privilege for locatio= n information, unless I need it.


-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]

Sent: Sunday, June 30, 2013 4:02 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

I'm not quite following you. I haven't tried all (or most) of these apps, b= ut the ones I have seen get notified on inbound calls, fetch the number-rel= ated information and then reject the call if found on the black list. This = works on Android; it may not work on IOS. Apparently, you may get one spurious ring in some cases. These are= real apps, not "what if". One of them claims 18 million users.
Maybe you can explain your concern in a bit more detail, as I'm obviously n= ot catching on.

________________________________________
From: DOLLY, MARTIN C [md3135@att.com= ]
Sent: Sunday, June 30, 2013 3:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

Understood what you said, you have not proven "existence proof", = as when I make a call on my mobile it does not interact with any other &nbs= p;app, so how does the "magic" happen for real, not "what if= " land.

-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: RE: [stir] Out-of-band vs. in-band

I said nothing about Google and using SIP, just that today there are Androi= d apps (not made by Google) that query an external database for every call = and use community rating to provide additional call-related information or = block the call as spam. This is essentially an out-of-band solution in the same general problem space. It = obviously doesn't address caller ID spoofing (except for some lazy robocall= ers that spoof the same number repeatedly - they exist), but provides an ex= istence proof that having an end system query a database per call is not a novel concept.

________________________________________
From: DOLLY, MARTIN C [md3135@att.com= ]
Sent: Sunday, June 30, 2013 2:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; stir@i= etf.org
Subject: Re: [stir] Out-of-band vs. in-band

Confused, so what is the problem space? Where does Google use SIP?

Martin Dolly
AT&T

Sent from my iPhone

On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov> wr= ote:

> The Google app store has several, if not dozens, of apps that query da= tabases for incoming calls, for displaying related information and user-ini= tiated blocking. To pick by download popularity, TrueCaller, Current Caller= ID, My Number-Block, WhosCall, Call Control, etc. (I have no idea how well any of them work - I'm just copying= names from the play.google.com we= b site...) These obviously don't address callerID spoofing, but they query = databases for incoming calls.
>
> There are distinct issues with out-of-band mechanisms, but I doubt tha= t user bandwidth or app availability are first-order concerns.
>
> ________________________________
> From: Eric Rescorla [ekr@rtfm.com]=
> Sent: Friday, June 28, 2013 1:28 PM
> To: Richard Shockey
> Cc: stir@ietf.org; Dave Crocker; = Henning Schulzrinne
> Subject: Re: [stir] Out-of-band vs. in-band
>
>
>
>
> On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <richard@shockey.us<mailto:richard@shockey.us>> wrote:
>
>
>
> This is not going to be generally true until the circuit switched netw= ork is mostly retired; customers hanging off a circuit switch aren't going = to be protected.
>
> Why is that true? A huge fraction of circuit switched devices are now = smartphones,
> which could absolutely make use of such a mechanism. In fact, that's p= recisely
> the environment for which the system in question was designed.
>
> [RS> ]  Frankly I would doubt that.  I would imagine the = mobile operators and Apple would object to anything that creates more signa= ling over the air.  Battery life. Its already an issue in VoLTE deploy= ments.  I have trouble imagining any E2E scenarios in a first phase deployment and Penn is absolutely correct that there are not= going to be any major retrofits of the legacy networks, certainly not in N= orth America.
>
>
> I'm really not following this.
>
> 1. We're talking about something on the order of 10KB of traffic/call.=
> My iphone uses this much bandwidth every time it polls my email
> server. This has a trivial impact on battery life.
>
> 2. It doesn't need a retrofit of the network, just the phone software.=
> That's the point.
>
> -Ekr
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

 

--_000_E42CCDDA6722744CB241677169E83656021D70D6MISOUT7MSGUSR9I_-- From dhc@dcrocker.net Sun Jun 30 13:27: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 3572A21F9C0A for ; Sun, 30 Jun 2013 13:27:50 -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 UZFeAJTzPiYq for ; Sun, 30 Jun 2013 13:27:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2D5321F9C50 for ; Sun, 30 Jun 2013 13:27:42 -0700 (PDT) Received: from [192.168.5.198] (ip-64-134-225-35.public.wayport.net [64.134.225.35]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5UKRbe6012946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Jun 2013 13:27:41 -0700 Message-ID: <51D094AF.2000507@dcrocker.net> Date: Sun, 30 Jun 2013 13:27:27 -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: Eric Rescorla References: <51C4CE80.40701@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.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]); Sun, 30 Jun 2013 13:27:41 -0700 (PDT) Cc: "stir@ietf.org" , Henning Schulzrinne , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band 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: Sun, 30 Jun 2013 20:27:50 -0000 On 6/30/2013 1:17 PM, Eric Rescorla wrote: > > On a smartphone, the dialer generally is an app. For instance: > > https://wiki.mozilla.org/Gaia/Dialer The lookups done by that dialer are to a /local/ contacts list, not an external one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ekr@rtfm.com Sun Jun 30 13:32: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 231EF21F9C4A for ; Sun, 30 Jun 2013 13:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.783 X-Spam-Level: X-Spam-Status: No, score=-101.783 tagged_above=-999 required=5 tests=[AWL=1.193, 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 3aa+nsX99XCI for ; Sun, 30 Jun 2013 13:32:47 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 185BB21F9C2D for ; Sun, 30 Jun 2013 13:32:47 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so1676540qab.11 for ; Sun, 30 Jun 2013 13:32:46 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=h54JzAPRGdUKWHNEwytTi4PCZrimXWDRA2Sowi3jezE=; b=oqUaSwf4f1FCE9NnxDH9WBTzV1dlh2b6meTB1HQee+hZMTzrok/Gi5IQ/VjSBGCFiE cEsjBHC0xRSaVOIkpEtMYubbnMu6G4I/RJZwHNaevWvCOmVXH2rWoYwveOAvVb/0EOdn ulj6VYVbvSUStnGelGjdNnaeuTmnE7ukrnKmnSWga9tgmuGC4kbm1TTOawNFvvOG//cc gsZGfYR9S31fRDF5ztYld84dvclPVxp544VNI6+ZliEkicHz0UIHTWBEpNZOi752C9vH EKY03Cj5/7nkYGSmJ9ef1hzzmJBEZj4C3Mfa29ihWlXBDG823jcsAz7OYHsuxpSzfjHh cExw== X-Received: by 10.229.31.202 with SMTP id z10mr6759823qcc.36.1372624366551; Sun, 30 Jun 2013 13:32:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Sun, 30 Jun 2013 13:32:06 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <51C89176.5000502@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> From: Eric Rescorla Date: Sun, 30 Jun 2013 13:32:06 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=14dae9d70b88c7605004e0650367 X-Gm-Message-State: ALoCoQmC/8yoIF41JDFUSUkl+dHmkoIJm5CHRQNbsMOKpokK1kYZqfROgkTENyfG6FsGapw2qWdh Cc: "stir@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:32:53 -0000 --14dae9d70b88c7605004e0650367 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C wrote: > Eric,**** > > ** ** > > My mother picks up her phone and she dials a number=85no app, even though > she has a smart phone. This is the user we have to protect=85 do you agre= e? > I'm not sure you and I have the same definition of "app". On a smartphone, the dialer is often (always?) a program that runs on the phone and that has access to the mobile dialer functionality. That's an app. Now, apps come in a number of flavors, depending on whether: - They are shipped with the phone or installed by the user. - What level of privileges they have. But I think Henning's point is that there is nothing particularly difficult about the smartphone manufacturer adding this sort of functionality to the builti= n dialer app. It's not an architectural change to the phone, just a new feature to a program. Is that something you disagree with? -Ekr --14dae9d70b88c7605004e0650367 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C = <md3135@att.com&= gt; wrote:

Eric,

=A0<= /p>

My mother picks up her ph= one and she dials a number=85no app, even though she has a smart phone. Thi= s is the user we have to protect=85 do you agree?


I'm not sure y= ou and I have the same definition of "app". On a smartphone, the = dialer
is often (always?) a program that runs on the phone = and that has access to the
mobile dialer functionality. That's an app. Now, apps come i= n a number of flavors,
depending on whether:

- They are shipped with the phone or installed by th= e user.
- What level of privileges they have.

=
But I think Henning's point is that there is nothing particu= larly difficult about
the smartphone manufacturer adding th= is sort of functionality to the builtin
dialer app. It's not an architectural change to the phone, j= ust a new feature
to a program. Is that something you disag= ree with?

-Ekr

--14dae9d70b88c7605004e0650367-- From ekr@rtfm.com Sun Jun 30 13:35: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 6F48621F9C0F for ; Sun, 30 Jun 2013 13:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.891 X-Spam-Level: X-Spam-Status: No, score=-101.891 tagged_above=-999 required=5 tests=[AWL=1.085, 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 m5ZkguNMDjA1 for ; Sun, 30 Jun 2013 13:35:50 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9E83221F9C05 for ; Sun, 30 Jun 2013 13:35:47 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so1644518qab.8 for ; Sun, 30 Jun 2013 13:35:47 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=yvD6h7poXHmviEHbJyAcJIZ4QsPZy76dr634w+1XgVM=; b=NRC1xLyjC5qCujEKhsKIdOm75YMA+qumrYcteBTp4ireMsFyXf+24BGmFi+p38aDPx IpZXBOgjbc1GIY2Tc+Q0+rJxGfI9Qh1fA9Sv7OBsf8ukfQLHd8Y3Uo+bbNTwHg1m7rxY Ltv/p9mOe6ALX3v1EpPl3yrBaAl4YBtSGLuCZV3gGLnCzPs1wH/nL6KpQaYx5jTxAyHr DgWgyAPhUX8c1+OAp+vQLlQgmW+txtPRLIEw5QXCqiDh+AZ5QtcUVluFdaqRbwdHMXG8 EsiiH6KBW52Qh2rrlLNSBVmV/ewrorDkrFiF418JNqKTu14svQnPPad7L8CexudwOaGf zkVA== X-Received: by 10.49.86.69 with SMTP id n5mr28050945qez.69.1372624547038; Sun, 30 Jun 2013 13:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Sun, 30 Jun 2013 13:35:05 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <51D094AF.2000507@dcrocker.net> References: <51C4CE80.40701@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <51D094AF.2000507@dcrocker.net> From: Eric Rescorla Date: Sun, 30 Jun 2013 13:35:05 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7bdc83b88958df04e0650e89 X-Gm-Message-State: ALoCoQmqvlmAVaSR3pcrjGdLMArcjjFfUmisBM9b8rAY1t2SWtOLWfFV96/SgED7C+HWd7LG28vV Cc: "stir@ietf.org" , Henning Schulzrinne , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:35:55 -0000 --047d7bdc83b88958df04e0650e89 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 30, 2013 at 1:27 PM, Dave Crocker wrote: > On 6/30/2013 1:17 PM, Eric Rescorla wrote: > >> >> On a smartphone, the dialer generally is an app. For instance: >> >> https://wiki.mozilla.org/Gaia/**Dialer >> > > > The lookups done by that dialer are to a /local/ contacts list, not an > external one. That's a pretty fuzzy distinction in the face of things like sync. Moreover, I'm not sure I see the relevance. Henning observed that you could get third party applications that do a db lookup with each call and so there was no in principle reason why the builtin phone application couldn't do the same thing. Obviously, the vendors would have to be induced to do so, but as far as I know there is no technical reason why that would be difficult for them to do, provided that such a service existed. -Ekr > --047d7bdc83b88958df04e0650e89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 30, 2013 at 1:27 PM, Dave Crocker <= ;dhc@dcrocker.net= > wrote:
On 6/30/2013 1:17 PM, Eric= Rescorla wrote:

On a smartphone, the dialer generally is an app. For instance:

https://= wiki.mozilla.org/Gaia/Dialer


The lookups done by that dialer are to a /local/ contacts list, not an exte= rnal one.

That's a pretty fuzzy d= istinction in the face of things like sync.

Moreover, I'm not sure I see the relevance. Henning observed= that you could
get third party applications that do a db l= ookup with each call and so there
was no in principle reaso= n why the builtin phone application couldn't do
the same thing. Obviously, the vendors would have to be induced = to do so,
but as far as I know there is no technical reason= why that would be difficult
for them to do, provided that = such a service existed.

-Ekr
=A0
=A0
--047d7bdc83b88958df04e0650e89-- From Henning.Schulzrinne@fcc.gov Sun Jun 30 13:39: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 C75A721F9C39 for ; Sun, 30 Jun 2013 13:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, 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 DLNcr1kgTOQh for ; Sun, 30 Jun 2013 13:39:21 -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 A394F21F9C31 for ; Sun, 30 Jun 2013 13:39:21 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "dcrocker@bbiw.net" , Eric Rescorla Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB01fXrRHtXUWe5nyT4KMtCplA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAEZUgP//wDsbAAoVkYD//73B+4AARjaAgAACS4CAAALQgP//vdM3 Date: Sun, 30 Jun 2013 20:39:19 +0000 References: <51C4CE80.40701@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> ,<51D094AF.2000507@dcrocker.net> In-Reply-To: <51D094AF.2000507@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 20:39:25 -0000 Let's see if we can agree on the observable facts as of today:=0A= =0A= * Standard smartphone dialers are apps.=0A= =0A= * There are event-driven apps that listen to incoming call events in the ba= ckground. They are used for a variety of purposes, including safe driving (= Sprint provides one like that; it auto-answers calls and texts when the pho= ne is in motion) and robocall prevention. I use one that provides a browser= pop-up on incoming calls (useful when I've muted my smartphone during a le= cture or meeting).=0A= =0A= * Some of these apps contact external databases for blacklisting and additi= onal-information (caller reputation) purposes.=0A= =0A= * The basic network interaction model of these current apps would probably = be pretty similar to the out-of-band validation apps discussed.=0A= =0A= * There are legitimate privacy concerns about who has access to call data. = A significant fraction of users would find that sufficiently disconcerting = to prevent them from installing such apps.=0A= =0A= * Regardless, millions of people have installed them since they apparently = find them better than the unfettered-robocalling alternative.=0A= =0A= Any disagreement on the above?=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Dave Crocker [dhc@dcrocker.net]=0A= Sent: Sunday, June 30, 2013 4:27 PM=0A= To: Eric Rescorla=0A= Cc: stir@ietf.org; Richard Shockey; Henning Schulzrinne=0A= Subject: Re: [stir] Out-of-band vs. in-band=0A= =0A= On 6/30/2013 1:17 PM, Eric Rescorla wrote:=0A= >=0A= > On a smartphone, the dialer generally is an app. For instance:=0A= >=0A= > https://wiki.mozilla.org/Gaia/Dialer=0A= =0A= =0A= The lookups done by that dialer are to a /local/ contacts list, not an=0A= external one.=0A= =0A= d/=0A= =0A= --=0A= Dave Crocker=0A= Brandenburg InternetWorking=0A= bbiw.net=0A= From md3135@att.com Sun Jun 30 14:36: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 45E8021F9C93 for ; Sun, 30 Jun 2013 14:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.968 X-Spam-Level: X-Spam-Status: No, score=-4.968 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Jtb5vmVFvoBW for ; Sun, 30 Jun 2013 14:36:29 -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 198D921F9C80 for ; Sun, 30 Jun 2013 14:36:29 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id dd4a0d15.2aaae562e940.7092490.00-556.19719317.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 30 Jun 2013 21:36:29 +0000 (UTC) X-MXL-Hash: 51d0a4dd16c89c10-89025582ff2de319151011f593fa5240818cb618 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 8d4a0d15.0.7092470.00-372.19719267.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 30 Jun 2013 21:36:28 +0000 (UTC) X-MXL-Hash: 51d0a4dc163de140-24aa3ab996d23ddbae43bb2694d74e1bf600dc56 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 r5ULaOxJ003424; Sun, 30 Jun 2013 17:36:24 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5ULa5oM003293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 17:36:05 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sun, 30 Jun 2013 21:35:55 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Sun, 30 Jun 2013 17:36:04 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] Out-of-band vs. in-band Thread-Index: AQHObffB9Ube0wumgUCN8mAR+HJsz5lA/mcAgARfFAD//9WzZYAARyoA///B17GAAQ/TgIAAYW+AgAA/UICAAAVDgIAABX+AgAF0k4CAAx4NgIAAB9CAgAAC/wCAABpmgIAAAXSAgAL2fjWAAANG1oAAR3IA///IVOAACMeoAAAIWHUw///BcICAAALQgIAAA1GA///MzAY= Date: Sun, 30 Jun 2013 21:36:03 +0000 Message-ID: References: <51C4CE80.40701@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> , <51D094AF.2000507@dcrocker.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=DcGwj5o7_7wA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=bQRfyHg_r70A:10 a=b8OvNEjo] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=pQs5aej7AAAA:8 a=k7Ga1wGzAAAA:8 ] X-AnalysisOut: [a=idmjnr6I4bGTvkifL2QA:9 a=CjuIK1q_8ugA:10 a=ClmATp4dOM8A:] X-AnalysisOut: [10 a=E1Snkw02GREA:10 a=lZB815dzVvQA:10] Cc: "stir@ietf.org" , Eric Rescorla , "dcrocker@bbiw.net" , Richard Shockey Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 21:36:34 -0000 Yes, you assume too much Martin Dolly AT&T=20 Sent from my iPhone On Jun 30, 2013, at 4:39 PM, "Henning Schulzrinne" wrote: > Let's see if we can agree on the observable facts as of today: >=20 > * Standard smartphone dialers are apps. >=20 > * There are event-driven apps that listen to incoming call events in the = background. They are used for a variety of purposes, including safe driving= (Sprint provides one like that; it auto-answers calls and texts when the p= hone is in motion) and robocall prevention. I use one that provides a brows= er pop-up on incoming calls (useful when I've muted my smartphone during a = lecture or meeting). >=20 > * Some of these apps contact external databases for blacklisting and addi= tional-information (caller reputation) purposes. >=20 > * The basic network interaction model of these current apps would probabl= y be pretty similar to the out-of-band validation apps discussed. >=20 > * There are legitimate privacy concerns about who has access to call data= . A significant fraction of users would find that sufficiently disconcertin= g to prevent them from installing such apps. >=20 > * Regardless, millions of people have installed them since they apparentl= y find them better than the unfettered-robocalling alternative. >=20 > Any disagreement on the above? >=20 > Henning >=20 > ________________________________________ > From: Dave Crocker [dhc@dcrocker.net] > Sent: Sunday, June 30, 2013 4:27 PM > To: Eric Rescorla > Cc: stir@ietf.org; Richard Shockey; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band >=20 > On 6/30/2013 1:17 PM, Eric Rescorla wrote: >>=20 >> On a smartphone, the dialer generally is an app. For instance: >>=20 >> https://wiki.mozilla.org/Gaia/Dialer >=20 >=20 > The lookups done by that dialer are to a /local/ contacts list, not an > external one. >=20 > d/ >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From ekr@rtfm.com Sun Jun 30 14:43: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 952EF21F9C4B for ; Sun, 30 Jun 2013 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 hDjoMjxZIRGR for ; Sun, 30 Jun 2013 14:43:44 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 316EE21F9C0A for ; Sun, 30 Jun 2013 14:43:44 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so1673263qab.19 for ; Sun, 30 Jun 2013 14:43:43 -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:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=xNqVXV6rvnOYXmptkOxyFMxQirJw/Gan1yVTN9d4+7c=; b=h+YQ+OtGQcsQD/ZGPtlwUVET2TnOMA5JVRWFR2CCChedaSMRcd6QgTiqMXnCspKYbD EwGFOwh1DVPVoT276uLZs7g7ZfeN/eBRbYJeDc0J6NygXiZxj7FcNs03QrDVnq7dnRP+ pZFVcvnwBFXsqct4Q/tXuUHvOaiqzI70C+heOJ8Z5wgf4my10ylqUpKfRyH3JSHCWKt6 YZZ2majgvSppHIVV5IUTASMse6zBAKHTgZzlp1JihHjBuRJM2UgvlhxP4WIWICRRl5M5 F50Kv7hefrmUvjaQvPfdNM8TrpROzmiphnWDR1Iu3rwBGFbwpeTU7r/7nb8tbXb0QyVG ly1w== X-Received: by 10.229.193.132 with SMTP id du4mr6790576qcb.32.1372628623662; Sun, 30 Jun 2013 14:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.137 with HTTP; Sun, 30 Jun 2013 14:43:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <51C4CE80.40701@dcrocker.net> <7049340A-B67D-4234-9DF7-767AF6827686@oracle.com> <51C9CC99.7020007@dcrocker.net> <1E0475FDD84F0C42A9F46570BB946FD941932E7E@PACDCEXMB01.cable.comcast.com> <009001ce7282$7d68acd0$783a0670$@shockey.us> <38726EDA2109264987B45E29E758C4D604974B18@MISOUT7MSGUSR9N.ITServices.sbc.com> <006401ce7424$1e7371d0$5b5a5570$@shockey.us> <939661CC-A122-4B04-A18D-8E00C94E4452@att.com> <51D094AF.2000507@dcrocker.net> From: Eric Rescorla Date: Sun, 30 Jun 2013 14:43:03 -0700 Message-ID: To: "DOLLY, MARTIN C" Content-Type: multipart/alternative; boundary=001a11c2921685b7e504e066014d X-Gm-Message-State: ALoCoQkBYKh6TitsB1lZnDurQwuoUhpK+4V/c89PjVS4U7JpIIjW6UdO/VQ7tRU3XBCBIsmoUsKL Cc: "stir@ietf.org" , Richard Shockey , "dcrocker@bbiw.net" , Henning Schulzrinne Subject: Re: [stir] Out-of-band vs. in-band X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 21:43:48 -0000 --001a11c2921685b7e504e066014d Content-Type: text/plain; charset=ISO-8859-1 It would be helpful if you could provide more detail about what you disagree with here. -Ekr On Sun, Jun 30, 2013 at 2:36 PM, DOLLY, MARTIN C wrote: > Yes, you assume too much > > Martin Dolly > AT&T > > Sent from my iPhone > > On Jun 30, 2013, at 4:39 PM, "Henning Schulzrinne" < > Henning.Schulzrinne@fcc.gov> wrote: > > > Let's see if we can agree on the observable facts as of today: > > > > * Standard smartphone dialers are apps. > > > > * There are event-driven apps that listen to incoming call events in the > background. They are used for a variety of purposes, including safe driving > (Sprint provides one like that; it auto-answers calls and texts when the > phone is in motion) and robocall prevention. I use one that provides a > browser pop-up on incoming calls (useful when I've muted my smartphone > during a lecture or meeting). > > > > * Some of these apps contact external databases for blacklisting and > additional-information (caller reputation) purposes. > > > > * The basic network interaction model of these current apps would > probably be pretty similar to the out-of-band validation apps discussed. > > > > * There are legitimate privacy concerns about who has access to call > data. A significant fraction of users would find that sufficiently > disconcerting to prevent them from installing such apps. > > > > * Regardless, millions of people have installed them since they > apparently find them better than the unfettered-robocalling alternative. > > > > Any disagreement on the above? > > > > Henning > > > > ________________________________________ > > From: Dave Crocker [dhc@dcrocker.net] > > Sent: Sunday, June 30, 2013 4:27 PM > > To: Eric Rescorla > > Cc: stir@ietf.org; Richard Shockey; Henning Schulzrinne > > Subject: Re: [stir] Out-of-band vs. in-band > > > > On 6/30/2013 1:17 PM, Eric Rescorla wrote: > >> > >> On a smartphone, the dialer generally is an app. For instance: > >> > >> https://wiki.mozilla.org/Gaia/Dialer > > > > > > The lookups done by that dialer are to a /local/ contacts list, not an > > external one. > > > > d/ > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > --001a11c2921685b7e504e066014d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would be helpful if you could provide more detail
a= bout what you disagree with here.

-Ekr
<= br>


On Sun, Ju= n 30, 2013 at 2:36 PM, DOLLY, MARTIN C <md3135@att.com> wrote:<= br>
Yes, you assume too much

Martin Dolly
AT&T

Sent from my iPhone

On Jun 30, 2013, at 4:39 PM, = "Henning Schulzrinne" <Henning.Schulzrinne@fcc.gov> wrote:

> Let's see if we can agree on the observable facts as of today:
>
> * Standard smartphone dialers are apps.
>
> * There are event-driven apps that listen to incoming call events in t= he background. They are used for a variety of purposes, including safe driv= ing (Sprint provides one like that; it auto-answers calls and texts when th= e phone is in motion) and robocall prevention. I use one that provides a br= owser pop-up on incoming calls (useful when I've muted my smartphone du= ring a lecture or meeting).
>
> * Some of these apps contact external databases for blacklisting and a= dditional-information (caller reputation) purposes.
>
> * The basic network interaction model of these current apps would prob= ably be pretty similar to the out-of-band validation apps discussed.
>
> * There are legitimate privacy concerns about who has access to call d= ata. A significant fraction of users would find that sufficiently disconcer= ting to prevent them from installing such apps.
>
> * Regardless, millions of people have installed them since they appare= ntly find them better than the unfettered-robocalling alternative.
>
> Any disagreement on the above?
>
> Henning
>
> ________________________________________
> From: Dave Crocker [dhc@dcrocker.n= et]
> Sent: Sunday, June 30, 2013 4:27 PM
> To: Eric Rescorla
> Cc: stir@ietf.org; Richard Shocke= y; Henning Schulzrinne
> Subject: Re: [stir] Out-of-band vs. in-band
>
> On 6/30/2013 1:17 PM, Eric Rescorla wrote:
>>
>> On a smartphone, the dialer generally is an app. For instance:
>>
>> https://wiki.mozilla.org/Gaia/Dialer
>
>
> The lookups done by that dialer are to a /local/ contacts list, not an=
> external one.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> __________________= _____________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir

--001a11c2921685b7e504e066014d-- From rlb@ipv.sx Sun Jun 30 15:42: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 49F9E21F9BF7 for ; Sun, 30 Jun 2013 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 bRkPqh-AYreC for ; Sun, 30 Jun 2013 15:42:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78921F9B21 for ; Sun, 30 Jun 2013 15:42:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so3639420obc.31 for ; Sun, 30 Jun 2013 15:42:01 -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=rlT1oLyk9M1bAO8LqpltOdmEIzGAg61XPASERKYLuZM=; b=mRC7r+GqBYgdtdG+e4EqgE6kdejZtAn/fpfN6D+vL488q1R5z5e3P+gitk9BFuX3T0 0J4V+meqcVQmOg0VBOV4cGuLOMs8FvJmyi7A4Ni6DgaKlETkGplS+UQDmEp169P/X1Kc 1KXaTzrz3bYyY2GV8jYaulw2CIqsx8c1KsIAVqmgb3kl0oqnAuzRGCuIV9YYV/jvsLXO QbUdw2SN3cWg0odwcC+eUll+JkQ8lsdt8cU6YpJqUnfT6JEgm7H5X06tC+ePLvfDCodF KkW1jwtFwT96RK9Gm0Gf00lQME8q1qzYJ6c7SWXOoBA7CfhgER5NgZreRLJEbg3c4jMC 8+7A== MIME-Version: 1.0 X-Received: by 10.182.27.74 with SMTP id r10mr9822484obg.63.1372632121846; Sun, 30 Jun 2013 15:42:01 -0700 (PDT) Received: by 10.60.26.135 with HTTP; Sun, 30 Jun 2013 15:42:01 -0700 (PDT) X-Originating-IP: [128.89.255.182] In-Reply-To: <003d01ce74d4$5c70ace0$155206a0$@shockey.us> References: <003d01ce74d4$5c70ace0$155206a0$@shockey.us> Date: Sun, 30 Jun 2013 18:42:01 -0400 Message-ID: From: Richard Barnes To: Richard Shockey Content-Type: multipart/alternative; boundary=089e01184b2e07b24c04e066d283 X-Gm-Message-State: ALoCoQlKxUrT/EIeOyvNi66c7BMbZJe49ZEINr2fZcHAkDSjILBuqizIptT+LPO5QewfUKBomT6u Cc: "stir@ietf.org" , Russ Housley , Brian Rosen Subject: Re: [stir] BOF Requirements... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.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, 30 Jun 2013 22:42:09 -0000 --089e01184b2e07b24c04e066d283 Content-Type: text/plain; charset=ISO-8859-1 We are currently scheduled for the longest slot and largest room available. --Richard On Sat, Jun 29, 2013 at 10:24 AM, Richard Shockey wrote: > Seriously, you guys better request a really big room as well and a large > time slot. > > You will have nearly the entire RAI and security communities attending. > > Needless to say don't schedule this against RTCWEB... :-) > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Friday, June 28, 2013 7:46 PM > To: Hadriel Kaplan > Cc: Wendt, Chris; Eric Rescorla; Dave Crocket; Richard Shockey; > stir@ietf.org; Dave Crocker; Henning Schulzrinne > Subject: Re: [stir] Out-of-band vs. in-band > > We have a BoF approved, and we have chairs for the BoF. We'll deal with > consensus in the charter discussion at the BoF. > > Brian > > On Jun 28, 2013, at 2:07 PM, Hadriel Kaplan > wrote: > > > > > On Jun 28, 2013, at 1:12 PM, Eric Rescorla wrote: > > > >> This seems like a digression, but surely you know well that mailing > >> list volume is not necessarily an accurate gauge of the views of the > >> group. > > > > Unfortunately that's all we have to go on for now. There is no WG. > > (fwiw, ISTM that many WG's in the IETF do in fact use email volume to > > gauge things, but I digress...) > > > > > >> Regardless, I don't think that there has been a sufficient level of > >> demonstrated consensus to justify the assertion of Hadriel's to which > >> I was replying. > > > > That's fair, and I should have been much more careful with what I said - > I > should have been clearer that I didn't mean unanimous agreement - we > definitely do NOT have that. I meant it more as a "I believe the majority > opinion is..." > > > > And it's certainly possible my perception of a thinking even that is > wrong, and that we might be evenly divided instead, or that even the > majority might favor having both in-band and out-of-band in the charter. I > don't *think* that's the case, but I could be wrong. > > > > I will say though that if I count the multiple personalities/voices in > > my head, I outnumber all of you. ;) > > > > -hadriel > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --089e01184b2e07b24c04e066d283 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We are currently scheduled for the longest slot and larges= t room available.=A0
--Richard

On Sat, Jun 29, 2013 at 10:24 AM, Richard = Shockey <richard@shockey.us> wrote:
Seriously, you guys better request a really = big room as well and a large
time slot.

You will have nearly the entire RAI and security communities attending.

Needless to say don't schedule this against RTCWEB... :-)

-----Original Message-----
From: stir-bounces@ietf.org [m= ailto:stir-bounces@ietf.org] O= n Behalf Of
Brian Rosen
Sent: Friday, June 28, 2013 7:46 PM
To: Hadriel Kaplan
Cc: Wendt, Chris; Eric Rescorla; Dave Crocket; Richard Shockey;
stir@ietf.org; Dave Crocker; Henning S= chulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

We have a BoF approved, and we have chairs for the BoF. =A0We'll deal w= ith
consensus in the charter discussion at the BoF.

Brian

On Jun 28, 2013, at 2:07 PM, Hadriel Kaplan <hadriel.kaplan@oracle.com>
wrote:

>
> On Jun 28, 2013, at 1:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> This seems like a digression, but surely you know well that mailin= g
>> list volume is not necessarily an accurate gauge of the views of t= he
>> group.
>
> Unfortunately that's all we have to go on for now. =A0There is no = WG.
> (fwiw, ISTM that many WG's in the IETF do in fact use email volume= to
> gauge things, but I digress...)
>
>
>> Regardless, I don't think that there has been a sufficient lev= el of
>> demonstrated consensus to justify the assertion of Hadriel's t= o which
>> I was replying.
>
> That's fair, and I should have been much more careful with what I = said - I
should have been clearer that I didn't mean unanimous agreement - we definitely do NOT have that. =A0I meant it more as a "I believe the ma= jority
opinion is..."
>
> And it's certainly possible my perception of a thinking even that = is
wrong, and that we might be evenly divided instead, or that even the
majority might favor having both in-band and out-of-band in the charter. = =A0I
don't *think* that's the case, but I could be wrong.
>
> I will say though that if I count the multiple personalities/voices in=
> my head, I outnumber all of you. ;)
>
> -hadriel
>

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


--089e01184b2e07b24c04e066d283--